Problem - Kevin Tafuro

11. The client and the server compute a master secret by concatenating the client
secret and the server secret, then hashing that with SHA1, truncating the result
to 128 bits.
12. Both the client and the server generate derived keys for encryption and
MAC’ing, as necessary.
13. The client and the server communicate using their new agreed-upon keys.
Incorporating either key transport or key exchange into a protocol that involves algorithm
negotiation is more complex. In particular, after keys are finally agreed upon,
the client must MAC all the messages received, then send that MAC to the server.
The server must reconstruct the messages the client received and validate the MAC.
The server must then MAC the messages it received (including the client’s MAC),
and the client must validate that MAC.
This MAC’ing is necessary to ensure that an attacker doesn’t maliciously modify
negotiation messages before full encryption starts. For example, consider a protocol
where the server tells the client which encryption algorithms it supports, and the client
chooses one from the list that it also supports. An attacker might intercept the
server’s list and instead send only the subset of algorithms the attacker knows how to
break, forcing the client to select an insecure algorithm. Without the MAC’ing, neither
side would detect the modification of the server’s message.
The client’s public key is a weak point. If it gets stolen, other people can
impersonate the user. You should generally use PKCS #5 to derive a
key from a password (as shown in Recipe 4.10), then encrypt the public
key (e.g., using AES in CWC mode, as discussed in Recipe 5.10).
The SSL/TLS protocol handles all of the above concerns for you. It provides either
one-way or two-way authenticating key exchange. (Note that in one-way, the server
does not authenticate the client using public key cryptography, if at all.) It is usually
much better to use that protocol than to create your own, particularly if you’re not
going to hardcode a single set of algorithms.
If you do not want to use a PKI, but would still like an easy off-the-shelf construction,
combine PAX (Recipe 8.15) with the secure channel from Recipe 9.12.
See Also
Recipes 4.10, 5.10, 7.14, 8.15, 9.1, 9.2, 9.12
Performing Authenticated Key Exchange Using RSA | 431
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.