### Attacks on protocols
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.
### Principles of protocol design
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.