# Protocols ### 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 protocols. [an95]: https://users.soe.ucsc.edu/~abadi/Papers/gep-ieee.ps **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.