Key agreement – A Secret to Share

3.6.2 Key agreement

From a security perspective, key transport has a fundamental downside compared to key agreement. If Alice generates the key and sends it to Bob (key transport), Bob can never be sure whether that key is sufficiently random.

This might seem quite paranoid at first (which is true for the cryptography mindset, but for a good reason), but Alice could unknowingly have a flaw in her random number generation or be tricked by Mallory, for example, to use an inadequate source of entropy.

Moreover, key transport typically relies on a long-term secret. If this secret gets lost, keys that were transported earlier also become known to Eve, meaning key transport does not provide forward secrecy. Thus, with key transport, Bob effectively needs to rely on Alice’s security capabilities and security posture when obtaining the shared secret key.

In contrast, key agreement is a key establishment process where the resulting secret key depends on data contributed by both Alice and Bob. Because both Alice and Bob provide their random input, neither of them can compute the secret key independently without the contribution of the other party.

As a result – in contrast to key transport – Bob can be sure that the shared secret key established during the key agreement is secure even if Alice’s input can be seen or guessed by the attacker.

Figure 3.3: In key agreement, the secret key is generated from the information dA provided by Alice and dB provided by Bob. Neither Alice nor Bob can predetermine the value of the secret key k independently of each other. The information dA and dB is transmitted over an unsecured channel, so Mallory can read and manipulate that data

Let’s take a look at an example of a key-agreement process where Alice uses a static key pair and Bob uses an ephemeral key pair [14]. The key agreement is carried out in four steps:

1. Bob acquires an authentic copy of Alice’s static public key PKAlice, for instance, from a so-called Certification Authority (CA). In this key agreement example, PKAlice is Alice’s contribution to the key agreement.
2. Bob generates an ephemeral (i.e., short-lived) key pair and sends its public key part EPKBob to Alice, keeping the private key part to himself. The ephemeral public key EPKBob is Bob’s contribution to the key agreement.
3. Alice and Bob use a mathematical operation involving their own private key and the other party’s public key to generate a shared secret k.
4. Both parties derive from k one or more additional keys to protect their subsequent conversation.

Ideally, a process called key confirmation is performed at the end of the key agreement to ensure that both Alice and Bob have generated the same identical key. For example, both could compute a Message Authentication Code (MAC; see Chapter 11, Hash Functions and Message Authentication Codes) of the previously exchanged messages involving the shared secret and send the resulting MACs to each other. Key confirmation is an important part of the TLS handshake protocol (see Chapter 6, Transport Layer Security at a Glance).