Prudent Engineering Practice for Cryptographic Protocols – Abadi & Needham, 1994
Prudent engineering practice for cryptographic protocols for most of us is not to design cryptographic protocols! Today’s paper serves to highlight how even the experts can get it wrong, and presents 11 design principles for cryptographic protocols – some of which may be useful in the design of other kinds of protocols too.
We present principles for the design of cryptographic protocols. The principles are not necessary for correctness, nor are they sufficient. They are however helpful, in that adherence to them would have contributed to the simplicity of protocols and avoided a considerable number of published confusions and mistakes. We arrived at our principles by noticing some common features among protocols that are difficult to analyze. If these features are avoided, it becomes less necessary to resort to formal tools- and also easier to do so if there is good reason to. The principles themselves are informal guidelines, and useful independently of any logic.
The authors observe that formal techniques can help to prove a design is correct, but give you no guidance in coming up with a correct design in the first place. A protocol in this paper is simply defined to be a set of rules or conventions defining an exchange of messages among a set of two or more partners. Of the 11 principles discussed in the paper, the first two are set above the rest as overarching principles.
Principle 1
Every message should say what it means: the interpretation of the message should depend only on its content. It should be possible to write down a straightforward English sentence describing the content-though if there is a suitable formalism available that is good too.
In other words, there is to be no implied context in which the message is to be evaluated.
Principle 2
The conditions for a message to be acted upon should be clearly set out so that someone reviewing a design may see whether they are acceptable or not.
For a message to be acted on, you have to trust it. What does trust mean? You should at least clearly set out what needs to be trusted in order to act on a message.
Principle 3
If the identity of a principal is essential to the meaning of a message, it is prudent to mention the principal’s name explicitly in the message.
This follows from the first principle. It is ‘obvious and simple, but commonly ignored.’
Principle 4
Be clear as to why encryption is being done. Encryption is not wholly cheap, and not asking precisely why it is being done can lead to redundancy. Encryption is not synonymous with security, and its improper use can lead to errors.
There are at least four different reasons the authors cite for why a protocol may be using encryption in a particular step. Protocol authors should be clear what the intended purpose is at each stage. Is it:
- To preserve confidentiality?
- To guarantee authenticity (that a message came from a particular sender)?
- To bind together the parts of a message?
While encryption guarantees confidentiality and authenticity, it also serves in binding together the parts of a message: receiving { X ,Y }K is not always the same as receiving { X }K and { Y }K. When encryption is used only to bind parts of a message, signature is sufficient. The meaning attached to this binding is rather protocol-dependent, and often subtle.
- To produce random numbers?
Principle 5
Don’t confuse the fact that a party signed an encrypted message, with the fact that a party knows the content of an encrypted message…
When a principal signs material that has already been encrypted, it should not be inferred that the principal knows the content of the message. On the other hand, it is proper to infer that the principal that signs a message and then encrypts it for privacy knows the content of the message.
Principle 6
Be clear what properties you are assuming about nonces. What may do for ensuring temporal succession may not do for ensuring association-and perhaps association is best established by other means.
Nonces are often used to avoid message replay attacks, as part of a challenge-response exchange. “A message is sent which leads to a reply which could only have been produced in knowl-edge of the first message. The objective is to guarantee that the second message is made after the first was sent, and sometimes to bind the two together. There is sometimes confusion about nonces-are they guaranteed new, random, unpredictable?”
It is not necessary for nonces to be unpredictable (you could use a counter). However, predictable nonces should be used with caution. This leads to principle 7…
Principle 7
The use of a predictable quantity (such as the value of a counter) can serve in guaranteeing newness, through a challenge- response exchange. But if a predictable quantity is to be effective, it should be protected so that an intruder cannot simulate a challenge and later replay a response.
Principle 8
If timestamps are used as freshness guarantees by reference to absolute time, then the difference between local clocks at various machines must be much less than the allowable age of a message deemed to be valid. Furthermore, the time maintenance mechanism everywhere becomes part of the trusted computing base.
Principle 9
A key may have been used recently, for ex-ample to encrypt a nonce, yet be quite old, and possibly compromised. Recent use does not make the key look any better than it would otherwise.
In other words, don’t confuse recency of use with recency of generation.
Principle 10
If an encoding is used to present the meaning of a message, then it should be possible to tell which encoding is being used. In the common case where the encoding is protocol dependent, it should be possible to deduce that the message belongs to this protocol, and in fact to a particular run of the protocol, and to know its number in the protocol.
If you choose to use a compact encoding, make sure there is no loss of information and no chance of confusing messages from different instances of the protocol.
Principle 11
The final principle builds on the second one:
The protocol designer should know which trust relations his protocol depends on, and why the dependence is necessary. The reasons for particular trust relations being acceptable should be explicit though they will be founded on judgement and policy rather than on logic.
An example is given with respect to timestamps:
The use of timestamps makes explicit for the first time a question of trust. When can a principal A rely on another principal B putting a correct timestamp in a message? The answer usually given is that this is acceptable if A trusts B in relation to timestamps…
Which leads to the general rule…
We may simply say that A trusts B in regard to some function if a loss of security to A could follow from B not behaving in the specified way; it is usually difficult or impossible for A to verify B’s good behavior. There is some measure of trust involved whenever one principal acts on the content of a message from another. It is essential that this trust be properly understood.
See the full paper for a more detailed exposition of the principles, and for examples in each case of protocols that violated the principle and hence ended up in trouble.