# 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 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. ## Exercises * 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)]*