# Protocol Design
We've now seen a number of attacks on protocols. Here's a categorization of attacks
that is useful in organizing our thoughts. Bear in mind that "immune against a list
of attacks" is not the same thing as "achieving security goals under stated assumptions."
* Eavesdropping: passively capturing messages. The primary countermeasure is encryption.
* Replay: record and resend messages. The primary countermeasure is nonces, usually in
conjunction with encryption and/or MACs. Special cases include preplay, reflection,
and man-in-the-middle attacks.
* Modification: actively alter messages. Splicing together of fields from separate
messages is perhaps more common than directly changing the bits of a single message.
The primary countermeasure is MACs. Typing attacks are a special case.
* Protocol: run a different protocol. The attacker is not bound to follow any
protocol narrations written by the designer.
The following principles were articulated in [[Abadi and Needham 1995][an95]].
The principles are neither necessary nor sufficient for the security of protocols,
but following the principles would have prevented a number of mistakes in published
**Main Principle: Every message should say what it means.** A good idea is to
write down an English description of each protocol message, then compare that
description to the contents of the message. Can the message be interpreted as is?
Or does the recipient have to supply context, about which it could become confused?
Protocol narrations can work against this principle, as narrations implicitly
provide a great deal of context, nearly all of which is under the control of the adversary.
**Principle: Message contents should describe what protocol,
which instance, and message number in it.** Otherwise, the recipient might confuse
messages within a protocol, between a current instance and an old instance of the
protocol, or even between different protocols.
**Principle: Explicitly name the relevant principals in each message.** Without
explicit names, the recipient has to guess from context. Many attacks
on key establishment protocols result from failure to name principals.
**Principle: Be clear about what cryptographic primitives are being
used, and why, and what properties of them are needed.** In particular,
beware when reading the literature that the properties required of encryption
sometimes are confused with MACs.
**Principle: A principal who signs a message that is already encrypted
can't be assumed to know the plaintext of that message.** Perhaps the
adversary got the principal to sign the ciphertext, or a hash of it.
**Principle: Be clear what properties are assumed of nonces.** Must
they be unique? Unpredictable?
**Principle: Don't use nonces in place of names.** Using names can actually
simplify protocols, so ask yourself which one you really want.
**Principle: Timestamps engender additional trust assumptions.**
If timestamps are used as nonces, then (i)
the difference between local clocks must be much less than the
allowable age of a message, and (ii) the time synchronization
mechanism becomes part of the TCB.
**Principle: A key that has been used recently might be old and compromised.**
That's true even if the key is used in conjunction with a fresh nonce.
**Principle: State what trust assumptions are necessary, and why.** That goes
for all of security, not just cryptographic protocols.
* Revisit the Bauer et al. and Denning & Sacco protocols from the previous
lecture. Write natural-language descriptions of each protocol step.
Evaluate both protocols against the principles set forth in this lecture.
Are there any changes you think should be made to the protocols to improve
their compliance with those principles?
* Consider an online game with many players, many game
hosts (which are servers who run the game), and a single trusted central
server S (which is involved in determining who is allowed to play
the game). Let P be a player, and H be a game host.
P already has a long-term symmetric key kPS
that is shared with S; it was established when P created
an account to play the game. H and S have well-known public keys
K_H and K_S. As part of playing an instance of the game, there is a
protocol that is needed: P connects to H,
and H checks with S to determine whether P really is allowed
to play. Design that protocol. Your protocol should make it impossible
for an attacker to wrongly authenticate with a host by intercepting
and replaying messages or by acting as a man-in-the-middle.
Write a protocol narration, explain each message in natural language,
and articulate what goals your protocol achieves.
*[acknowledgment: Tom Chothia (Univ. of Birmingham)]*