Origin Authenticity
Data origin authentication is inherently supported by secret key cryptography provided that the key is shared by two entities only. When three or more parties share the same key, origin authenticity can no longer be provided by secret key cryptography alone. Various secret-key based authentication protocols have been developed.
Figure 1.7 illustrates the steps of a simple secret-key authentication protocol executed by entities A and B. Authentication is established by presenting the proof of possessing the secret key K. In order for A to authenticate B, it first generates a random value R1, keeps a copy, and sends B a message that contains R1. B applies E(R1, K) to encrypt R1, forms a message with B's identity and the encrypted value; then sends it to A. In turn, A applies D(R1, K) to decrypt R1 and compares the decrypted value with the one it had generated. Similar steps are used to authenticate A to B with B being the initiator and using its own R2 value.
FIGURE 1.7 A basic secret-key authentication protocol
Authentication protocols such as the one we just described, require careful and thorough reviews. This simple protocol is flawed and is susceptible to what is known as a reflection attack in which an eavesdropper V may masquerade as entity A and authenticate to B as such. V takes advantage of the fact that B is willing to encrypt any challenge value. V, therefore pretending to be A, generates R2 and asks B to encrypt it. B replies with a random value R1 for V (pretending to be A) to encrypt so that it authenticates itself. Meanwhile V starts another authentication session with B and picks the same value, R1, received from the pending authentication session and sends it to B, which replies with R1 encrypted. Now V goes back to the first session and sends B this encrypted value, therefore authenticating itself to B as entity A.
One way of fixing this protocol is to insist on always having different values for the challenge from the initiator and that from the responder.