Step-by-Step Key and Message Exchange (CNG Example)

Cryptographic private/public key solutions are susceptible to man-in-the-middle attacks. These attacks take a variety of forms, including eavesdropping, substitution, denial of service, and phishing. The Cryptography Next Generation (CNG) secure communication example addresses substitution, in which a third party (Mallory) inserts himself between two communication endpoints (Alice and Bob).

The following sections provide background information, illustrations, and step-by-step instructions for the five security versions discussed in the CNG example overview:

• Version 1: Basic message exchange

• Version 2: Unsigned key and unsigned message exchange:

  • Without interception

  • With interception

• Version 3: Signed key and signed message exchange

• Version 4: Signed key and signed message exchange with detection

• Version 5: Signed key and signed message exchange with application termination

Version 1: Basic Message Exchange

The following illustration shows Alice and Bob sending messages without a man-in-the-middle attack. The messages are not encrypted or digitally signed. The CNG example demonstrates this procedure when you select version 1. A step-by-step description of the process is provided after the illustration.

Version 1: Basic message exchange

Alice and Bob send unencrypted, unsigned messages

1. Alice creates a message.

2. Alice sends the message to Bob.

3. Bob receives Alice's message.

4. Bob creates a message.

5. Bob sends the message to Alice.

6. Alice receives Bob's message.

Version 2: Unsigned Keys and Unsigned Messages Without Interception

The following illustration shows key and message exchange without a man-in-the-middle attack. The CNG example demonstrates this procedure when you select version 2 and turn off interception by Mallory. A step-by-step description of the process is provided after the illustration.

Version 2: Unsigned keys and unsigned messages without interception

Alice and Bob create their keys

1. Alice generates a public/private key pair.

2. Alice sends her public key to Bob.

3. Bob stores Alice's public key.

4. Bob generates a public/private key pair.

5. Bob sends his public key to Alice.

6. Alice stores Bob's public key.

Alice and Bob derive matching key material

7. Alice uses her private key and Bob's public key to generate a shared secret agreement. She uses the shared secret agreement to derive the key material.

8. Bob uses his private key and Alice's public key to generate the same shared secret agreement. He uses the shared secret agreement to derive the same key material as Alice.

For more information about shared secret agreements and key derivation, see Overview of the ECDH Algorithm (CNG Example).

Alice and Bob send each other messages

9. Alice creates a message and encrypts it with the key material.

10. Alice sends the encrypted message to Bob.

11. Bob receives and decrypts the message.

12. Bob creates a message and encrypts it with the key material.

13. Bob sends the message to Alice.

14. Alice receives and decrypts the message.

Version 2: Unsigned Keys and Unsigned Messages with Interception

The following illustration shows key and message flow with a man-in-the-middle attack. The CNG example demonstrates this procedure when you select version 2 and enable interception by Mallory.

Version 2: Unsigned keys and unsigned messages with interception

Mallory impersonates Bob

1. Alice generates a public/private key pair.

2. Alice sends her public key to Bob.

3. Mallory intercepts and stores Alice's public key.

4. Mallory generates his own public/private key pair for use with Alice.

5. Mallory sends his public key to Alice, deceiving her into thinking it is from Bob.

6. Alice stores Mallory's public key, believing it is Bob's key.

Mallory does not establish a channel to Bob until after he has completed his key exchange with Alice. He does this because he shares the PublicChannel with Alice (see Source Code Overview). He has to send Alice his substitute key before he can close PublicChannel, reopen it, and then connect with Bob.

Compare this with steps 17-22, where messages sent by Alice are transferred through to Bob.

Mallory impersonates Alice

7. Mallory generates a second public/private key pair for use with Bob.

8. Mallory sends his public key to Bob.

9. Bob stores Mallory's public key, believing it is Alice's key.

10. Bob generates a public/private key pair.

11. Bob sends his public key to Alice.

12. Mallory intercepts and stores Bob's public key.

Alice and Mallory derive matching key material

13. Alice uses her private key and what she believes is Bob's public key (actually, the public Mallory/Alice key) to generate a shared secret agreement. She uses the shared secret agreement to derive the Mallory/Alice key material.

14. Mallory uses his private key and Alice's public key to generate the same shared secret agreement. He then uses the shared secret agreement to derive the same key material as Alice.

Bob and Mallory derive matching key material

15. Mallory uses his private key and Bob's public key to generate a shared secret agreement. He uses the shared secret agreement to derive the Mallory/Bob key material.

16. Bob uses his private key and what he believes is Alice's public key (actually, the public Mallory/Bob key) to generate the same shared secret agreement. He then uses the shared secret agreement to derive the same key material as Mallory.

Note

After steps 13 and 16, Alice and Bob think that they are sharing the same key material. Actually, they are not sharing their key material with each other, but with Mallory.

Alice sends Bob a message

At this point, Mallory can engage in a dual conversation because he has two open pipes available for use. This differs from steps 1-6, where Mallory opened one channel at a time to intercept the cryptographic keys.

17. Alice generates a message and encrypts it by using the Mallory/Alice key material that she generated in step 13. She tells Bob about a potential sales contact.

18. Alice sends the message to Bob.

19. Mallory intercepts and decrypts the message. He steals the contact information.

20. Mallory generates a fake message that is based on Alice's message, but he changes the contact address. He encrypts the fake message by using his shared Mallory/Bob key material.

21. Mallory sends the message to Bob.

22. Bob decrypts the message, believing it is from Alice.

Bob sends Alice a message

23. Bob generates a message and encrypts it by using the Mallory/Bob key material that he generated in step 16. He tells Alice that he looks forward to meeting the contact.

24. Bob sends the message to Alice.

25. Mallory intercepts, decrypts, and discards the message.

26. Mallory generates a fake message by using his shared Mallory/Alice key material. He tells Alice that he thinks the sales contact's address was incorrect, but that he will continue to try reaching the contact.

27. Mallory sends the message to Alice.

28. Alice decrypts the message, believing it is from Bob. She accepts his explanation and moves on to other clients.

Version 3: Signed Keys and Signed Messages with Interception

The following illustration shows cryptographic key and message flow, a man-in-the-middle attack, and the use of digital signatures to sign keys and messages. The CNG example demonstrates this scenario when you select version 3 and enable interception by Mallory.

Version 3: Signed keys and signed messages with interception

Version 3 is identical to version 2, except that it demonstrates the use of a digital signature to sign messages and cryptographic keys.

In steps 1-6, Alice sends the digital signature key on the nonsecure PublicChannel where it is intercepted by Mallory, who uses it to sign his substituted keys and messages. As a result, Alice, Bob, and Mallory use the same digital signature key. When Alice and Bob validate key and message signatures in steps 15, 20, 35, and 42, they do not detect Mallory's interception.

Version 4: Signed Keys and Signed Messages with Detection

The following illustration shows cryptographic key and message flow, a man-in-the-middle attack, and the use of digital signatures to sign keys and messages. In addition, the version 4 software detects invalid signatures. The CNG example demonstrates this scenario when you select version 4 and enable interception by Mallory.

Version 4: Signed keys and signed messages with detection

Version 4 differs from version 3 in the following ways:

• The version 4 software is given only to Alice and Bob.

• Version 4 sends the digital signature key that was used in version 3, but treats it as a fake key.

• Version 4 enables Alice to send Bob a second digital signature key through a private channel that Mallory does not know about. (This is step 0 in the previous illustration.) Alice and Bob use this private digital signature to sign their keys and messages.

• Version 4 detects Mallory's invalid signatures in steps 15, 20, 35, and 42, and displays security warnings.

Mallory continues to use the version 3 digital signature to sign his substituted keys and messages. As a result:

• He does not know about the version 4 private digital signature key.

• He does not receive security warnings.

• He does not know that Alice and Bob can detect his invalid key and message signatures.

Version 5: Signed Keys and Signed Messages with Session Termination

The following illustration shows cryptographic key and message flow, a man-in-the-middle attack, and the use of digital signatures to sign keys and messages. As in version 4, invalid signatures are detected. The CNG example demonstrates this scenario when you select version 5 and enable interception by Mallory.

Version 5: Signed key and signed messages with termination

Version 5 is identical to version 4, except that the session ends when Alice and Bob receive public cryptographic keys with invalid digital signatures.

See Also

Concepts

Cryptography Next Generation (CNG) Secure Communication Example

Other Resources

Cryptographic Services