Cryptography Reference
In-Depth Information
PROTOCOL ANALYSIS
We now analyse this protocol to see if it meets the typical goals of an AKE protocol
specified in Section 9.3.1.
Mutual entity authentication : We will divide this into two separate cases.
1. First we look at Bob's perspective. At the end of the fourth protocol message,
the second ciphertext that Bob receives is an encrypted version of his nonce
r B . Thus this ciphertext is fresh. But who encrypted it? Whoever encrypted
it must have known the key K AB . Bob received this key by successfully using
K BT to decrypt a ciphertext, which resulted in a correctly formatted plaintext
message consisting of r B , K AB and Alice's name. Thus Bob can be sure that this
ciphertext originated with the TTP, since the TTP is the only entity other than
Bob who knows K BT . The format of this plaintext is essentially an 'assertion' by
the TTP that the key K AB has been freshly issued (because r B is included) for
use in communication between Bob (because it is encrypted using K BT ) and
Alice (because her name is included). Thus the entity that encrypted the second
ciphertext in the fourth protocol message must have been Alice because the
TTP has asserted that only Alice and Bob have access to K AB . Hence Bob can
be sure that he has just been talking to Alice.
2. Alice's perspective is similar. At the end of the last protocol message, Alice
receives an encrypted version of her nonce r A . This ciphertext, which was
encrypted using K AB , is thus fresh. In the third protocol message Alice receives
an assertion from the TTP that K AB has been freshly (because r A is included)
issued for use for communication between Alice (because it is encrypted using
K AT ) and Bob (because his name is included). Thus the entity that encrypted
the last protocol message must have been Bob, again because the TTP has
asserted that only Alice and Bob have access to K AB . Thus Alice can be sure
that she has just been talking to Bob.
Note that our assertions that only Alice and Bob have access to K AB of course
assume that the TTP is not 'cheating', since the TTP also knows K AB . However,
the whole point of this protocol is that the TTP is trusted not to misbehave in
this type of way.
Mutual data origin authentication : This is interesting, because we use symmetric
encryption throughout this protocol and do not apparently employ any
mechanism to explicitly provide data origin authentication, such as a
MAC. While symmetric encryption does not normally provide data origin
authentication, recall the 'case for' in our analysis of Protocol 4 in Section 9.3.5.
Throughout our current protocol, the plaintexts are strictly formatted and
fairly short, hence it might be reasonable to claim that encryption alone is
providing data origin authentication, so long as a strong block cipher such as
AES is used. However, the standard ISO 9798-2 goes further, by specifying
that the 'encryption' used in this protocol must be such that data origin
authentication is also essentially provided. One method would be to use an
Search WWH ::




Custom Search