Introduction
Key exchange is a necessary operation which aims to obtain a secure channel between two or more users in a network. Since security is usually obtained through the encryption of the data flowing over untrusted channels, the keys to encrypt/decrypt such data in a meaningful way must be shared among the channel users. This step is always present in common cryptographic operations, and it's usually part of the session establishment. Two users, Alice and Bob, which desire to exchange secure data between themselves need to agree on the cipher and key used to secure the data.
In this Article I'll introduce the basic and common protocols used for this operation. Take into account that some of the given protocols alone are not enough to obtain security over the desired connection. Additional features like Authentication, Signatures and Digital Identities will be presented in the nexts Articles.
A small and independent set of prototypes are available to be downloaded at the head of the Article. This utilities allows to touch with your hands the concepts presented in the following chapters.
Background
The reader is supposed to posses a good knowledge about C programming language, GCC Building Toolchains, Networks and Socket programming and Linux Operating system. It's not necessary to be confident with OpenSSL and Libcrypto, as a wrapper between the prototypes and this library will be introduced together with the source.
I also warmly advise to read "Applied Cryptography: Protocols, Algorithms, and Source Code in C" textbook from Bruce Schneier, since it has been used as the primary source of information for the development of the code and as a guideline to write this Article. In addition, the Internet provides a lot of easily accessible sources (usually more updated) on such subjects: you just have to search for it.
Crypto wrapper
Usually a Software Engineer want to interpose between himself and reality (or the problem) as much level of abstraction as possible. To protect myself from a particular cryptographic library implementation, I'm introducing this small wrapper which will be providing to me a simple API that hides all the details. The wrapper currently works only over OpenSSL primitive library libcrypto on Linux, but I will keep it flexible enough to extend some other libraries in the future (who knows).
The design of such software aims to maintain the simplicity of Unix-like API, while still trying to offer as more flexibility and functionalities as possible. In addition to that, this wrapper has been designed to operate mainly on low level functionalities of OpenSSL, so the design of the protocol is up to you. You will not find a magic "EstablishSession" procedure which will do everything from scratch, but rather you need to design the interactions and state machine behind the cryptographic feature you need to perform (no lazy programmers allowed).
The API is really small right now. The following routines allows the developer to reserve a cryptographic descriptor for future use. The descriptor will be accessible by using the integer identifier returned.
void CryptClose(int cd);
int CryptOpen();
Descriptors are limited to CRYPTO_HANDLES_MAX amount, which should be provided at compile time. Trying to allocate more than that will result the wrapper in generating an error (negative value). The descriptor in "Open" state is not usable and must be initialized to perform any of the available specific cryptographic operations.
int CryptAES(int cd, int bits, unsigned char * key, unsigned char * iv, int flags);
int CryptRSA(int cd, char * key, int len, int flags);
Currently only AES CBC and RSA ciphers are available, and provides Symmetric and Asymmetric ciphers for cryptography used by the software. New modes will be hopefully available in the future.
Once the descriptor has been initialized in its specialized mode, what you need to do is just perform Encryption/Decryption with the given data. To perform such operations use the following procedures:
int Decrypt(
int cd,
char * plain,
unsigned int plen,
char * cipher,
unsigned int clen);
int Encrypt(
int cd,
char * plain,
unsigned int plen,
char * cipher,
unsigned int clen);
All the public procedures offered by the API are thread-safe, meaning that the abstraction will maintain synchronization between different contexts (using pthread mutexts for descriptor allocations and encryption/decryption procedures).
WARNING: This wrapper is in an absolute Alpha state, and I do not advise you to use it in any other project outside this small "cryptography laboratory". As other subjects will be introduced in the future articles, you will see the shape of the wrapper evolving to accomodate more and more requirements.
Naming convention
The following naming/style convention will be adopted in the article:
- Alice, Bob and Carol will be users which want to exchange data in a secure way.
- Eve will be the name of the Service Provider, and will perform eavesdropping of the data exchanged between the users.
- Mallory will be the Service Provider which will try to perform some alteration of the traffic exchanged between the legit users.
- Trent will assume the role of the authority trusted by all the network users.
- A clear text message will be represented by the variable m.
- An encrypted message will be represented by the variable c.
- Symmetric encryption operated on a message using, for example, Alice key will be written as:
- Symmetric decryption operated on a ciphertext using, for example, Alice key will be written as:
- In case of Asymmetric chipers, encryption and decription will be specified to user public (P, upper-case) or private (p lower-case) keys as follows:
,
Key Exchange using Symmetric ciphers
Symmetric ciphers works by using the same key to encrypt and decrypt a message. This means that the users of the secure channel must be in posses of the same key in order to write and read in a way that is comprehensible by all the users. For the problem of the Key Exchange, you need to move this key from Alice to Bob without having any intermediate eavesdropper acquire the key.
To work this protocol need a trusted third user, Trent, which will act as a mediator for the session creator. Alice and Bob have already a key used for protect secrets between them and Trent. I suppose such key has already been ecretly provided by hand or through another conventional channel.
The protocol with Symmetric key works like the following:
- Alice contact Trent using Alice-Trent key, and ask for a session with Bob.
- Trent prepare a session key, and encrypts it using Bob-Trent key. It then attach (concatenate) it to the session key in clear, and encrypts everything with Alice-Trent key, sending everythin then to her.
- Alice decrypts whatever Trent send to her. This information contains the Alice-Bob session key and an encrypted part that Alice is not able to decrypt (and so to alter).
- Alice sends this last part (not readable by her) to Bob.
- Bob receive the message and decrypt it with Bob-Trent key, which is private between these users and not known to anyone else. The decrypted message will contains the same session key that Alice has received.
- Alice and Bob start to communicate using the newly acquired session key.
This protocol depends on availability and trust towards Trent. If Trent servers are not reachable for any cause, the communication will not take place since it will be not possible to create a session key between Alice and Bob. The entire architecture is highly centralized towards Trent services and ability to use unique keys known only by Alice/Bob and the trusted user.
Key Exchange using Symmetric ciphers with multiple users
The protocol can be extended to operate with more than two users; what is necessary to do is to instruct Alice to dispatch the right encrypted part to the right user. Take into account that Eve in this case is not able to realize what kind of information is being exchanged, but can directly realize who will be the participant of such conversation by looking at the destination name of the unknown message.
This should work as follows:
- Alice ask for a session with Bob and Carol to Trent.
- Trent creates a copy of the session key for each participant, and encrypts each copy using a private key only known by the participant and him. This means that the message will be organized in the following format:
- Alice decrypts the message, thus discovering the session key that will be used for the communication. It then proceed in sending to the respective destination those parts that are reserved and unreadable to her.
- Bob and Carol will receive a message encrypted with the key known only by them and Trent, and will use such key to perform the disclosure of the session key.
Alternatively Alice can send the entire encrypted part to the next element in the "chain", which will decrypt its part and send again everything to the next. The operation proceed until the last one acquire the key and send a signal to inform that everyone in the chain is ready. This operation does not really hide who will be a member of this conversation, but makes it more difficult to trace once the users carries multiple communication channel at the same time. Not to speak that is way harder to control the communication between different hosts rather than the communication of a single host, so just looking at Alice traffic wont help identifying everyone in this case.
- Alice ask for a session with Bob and Carol to Trent.
- Trent creates a copy of the session key for each participant, and encrypts the key in the "chain" reverse order. This means that the message will be organized in the following format:
- Alice receive the message, decrypts it and discover the session key.
Then send the unreadable part to Bob.
- Bob receive the message, decrypts it and discover the session key.
Then send the unreadable part to Carol.
- Carol receive the message, decrypts it and discover the session key. Now no more data to send is appended at the end of the message, so it report back to Bob, using the session key, that she is ready to start the session interaction.
- This feedback traverse backward the chain until Alice receive the feedback and finally start the communication with the other nodes.
This last extension of Symmetric Key exchange with multiple, chained, users can be of some use in systems like Onions Networks, where communication sessions needs to be established between multiple nodes in a defined circuit. In such case Alice is the session initiatior, and the chain is the circuit which should exchange the session key to be able to perform the encryption/decryption of the data passing by.
Symmetric example
You can build the entire project by invoking the make at the root directory, or build single experiment separately. Change the directory to Basic/KeyExchange/Symmetric to access the Symmetric Key Exchange software. Prepare four consoles in order to run one user per console, then start with Eve (or otherwise the other users cannot communicate between themselves).
The second user to run has to be Trent, since he is the trusted node of this small network. If successfully started the console will report the following feedback:
Basic Cryptography: Symmetric Key exchange
Setting up cryptographic contexts...
1/2 Initializing Alice context............DONE
2/2 Initializing Bob context..............DONE
Initializing network..........................DONE
Presenting to network provider................DONE
You will also notice that Eve will be aware of his presence in the network.
Third step is to run Bob, since it will be passively waiting for Alice to exchange with him the session key encrypted with his and Trent secret key. If successfully started the console will report the following feedback:
Basic Cryptography: Symmetric Key exchange
Preparing Cryptographic contexts...
1/2 Preparing Bob-Trent context...........DONE
2/2 Preparing Alice-Bob context...........DONE
Initializing network..........................DONE
Presenting to network provider................DONE
Again, Eve at this time will also be aware of Bob presence in the network.
Last step is to run Alice in another console. If successfully started the console will report the following feedback:
Basic Cryptography: Symmetric Key exchange
Preparing Cryptographic contexts...
1/2 Preparing Alice-Trent context.........DONE
2/2 Preparing Alice-Bob context...........DONE
Initializing network..........................DONE
Presenting to network provider................DONE
Requesting session key to Trent...............DONE
Decrypting arrived message....................DONE
Alice-Bob session key: 51 bf 5f c1 27 78 d0 1a 42 80 66 86 e4 5d c8 d2 03 be 91 5f 7a 2a d1 e3 1b c4 7d 78 dd df e7 2f
Input vector: 9e 47 f0 c6 bf c0 e0 01 40 46 87 24 a3 4f f6 a6
Preparing Alice-Bob session...................DONE
Sending session information to Bob............DONE
Secret messages from Bob:
Hello Alice, this is Bob!
Terminating...
At this point Eve will be aware of the presence of Alice in the network. In addition to that you will also see in Eve console Alice asking for a session with Bob with the message:
Received 2 bytes --> ToTrent
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 00 00
Trent reacts to this empty message by generating the session key and sending it in its encrypted for to Alice. This leaves in Eve console the following trace:
Received 128 bytes --> ToAlice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 56 0f 07 6b a3 6c e7 94 89 6c 83 db b2 e9 e5 72
010 25 22 50 9e 0a 30 d2 cf f8 28 47 22 ab 85 e4 7c
020 1f 19 c0 c8 97 4f 85 f6 11 23 6b e4 50 b8 94 c7
030 dc c0 1a 3c a9 23 c9 09 50 cc 6f aa d8 12 5e 3b
040 85 23 d2 57 fd ca ae 13 88 26 b0 66 55 b9 fc 0c
050 9f 36 35 5c 39 4e c2 bd ae e7 ec b0 85 a8 42 b7
060 58 96 b4 b9 6b 53 c9 a6 8f 09 55 87 19 df 6c 70
070 5d 93 61 02 44 5a dd 5f d5 a5 62 1d cb 53 8f 49
As you can see now the message is encrypted (the size of the message, for example, which is not 32 (key) +16(IV) bytes, but is aligned blocks of AES-256 output). Nowhere you will be able to see session information in a clear format.
Alice then proceed to decrypt the arrived message, and extracts the session information. Now it's her turn to send to Bob the session details, which are still unreadable to her (but she can still presume they will be the same). This leaves in Eve the following trace:
Received 64 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 a9 ee a4 8c 00 f3 7e c2 45 3d 03 b5 1c d4 aa 98
010 78 3e 7e 4d 2d 0f 67 33 8c b8 f8 34 f1 4b 1a 10
020 80 2c ec da 05 40 47 21 4a a0 0e d8 f4 03 2a 80
030 75 10 66 1b 37 21 3e da ff b2 68 3e 5c 9c 9c 15
Bob software then decrypts the message, extracts the session key and use them to send an encrypted Hello to Alice. This leaves the following final trace in Eve console:
Received 32 bytes --> ToAlice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 23 72 c6 ac dd 11 7b 92 36 88 ee 2a 29 a0 2b 12
010 4f f5 c6 d5 b2 53 44 19 eb 03 f6 94 a0 70 a4 a4
Key Exchange using Asymmetric ciphers
Asymmetric ciphers differs from the symmetric one in he number of keys used for encryption and decryption. Asymmetric ciphers key come in pairs: one of the key (the public one) is used to encrypt a message, and the other one (the private key) to decrypt it. Information which is encrypted with one key cannot be decrypted (in reasonable time, with reasonable resources) without the other.
An user which generates a couple of asymmetric key wants in general to publish his public key, while keeping private the other key.
The protocol for key exchange behaves as follow:
- Alice generates a couple of asymmetric keys, one private and the other public.
She then share the key with Bob as it is.
- Bob generates a couple of asymmetric keys, one private and the other public.
When he receive Alice public key, he will answer with his public key.
- Using Bob public key Alice then can start to communicate with him, and vice versa.
- The message is then decrypted by Bob by using his own private key.
As you can see now the protocol has become way simpler to handle and the key exchange happens without any intermediate actor. But this comes at a cost. First, operation with asymmetric ciphers are more expensive, and encrypting/decrypting messages becomes slower. Second, used without any additionl security this initial message exchange is prone to be broken with a man-in-the-middle attack (we will see this in the next chapter).
Asymmetric example
As for symmetric example, you can build this altogether from the root directory or by moving to the folder Basic/KeyExchange/Asymmetric and invoking make from there. The building process will prepare the public and private keys for Alice and Bob (if they have not been already generated), and then proceed with building Alice, Bob and Eve applications.
Again, start Eve as a first step to allow Alice and Bob communication to take place. After Eve you can run Bob in another onsole; the feedback visible on his terminal will be:
Basic Cryptography: Asymmetric Key exchange
Setting up cryptographic contexts...
1/2 Loading private key...................DONE
2/2 Loading public key....................DONE
Initializing network..........................DONE
Presenting to network provider................DONE
and the application will start to wait for a feedback from Alice. Eve will be able from now on to forward messages to Bob, since he has registered to the network service. The trace on Eve console at this point is:
Received 0 bytes --> Bob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000
Bob on port 53911
Now run Alice on the other console. This will generate the following output on her console:
Basic Cryptography: Asymmetric Key exchange
Setting up cryptographic contexts...
1/2 Loading private key...................DONE
2/2 Loading public key....................DONE
Initializing network..........................DONE
Presenting to network provider................DONE
Preparing Bob context...
1/3 Requesting Bob public key.............DONE
2/3 Receiving the key.....................DONE
3/3 Preparing Bob context.................DONE
Key received from Bob:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49
010 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49
020 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41
030 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43
040 67 4b 43 41 51 45 41 79 62 4a 6c 6d 62 51 64 71
050 6d 4e 62 45 4a 6e 37 57 67 6c 5a 0a 4b 53 52 6a
060 58 51 36 77 47 43 76 74 50 69 6c 48 65 32 2f 6f
070 71 70 54 38 50 36 53 4d 50 79 42 48 68 47 69 67
080 6b 70 75 45 48 34 50 34 65 35 36 72 74 66 2f 51
090 73 75 5a 70 57 68 79 63 64 49 65 61 0a 6f 69 73
0a0 58 64 63 69 56 33 66 46 6d 4a 56 38 45 6c 33 65
0b0 70 57 75 77 64 4f 41 66 79 70 54 4d 42 69 71 70
0c0 38 6d 32 64 6b 41 51 70 57 63 36 66 5a 55 57 53
0d0 59 54 6c 36 39 5a 6a 48 56 39 39 55 56 0a 35 6d
0e0 4c 4f 55 30 4a 46 50 59 44 71 6c 4c 70 74 55 59
0f0 4c 38 4f 53 33 48 51 6e 4f 4f 56 6d 64 6d 65 4a
100 2b 34 68 50 72 31 39 55 48 6f 39 66 64 33 39 2f
110 76 74 62 6a 7a 4a 33 35 47 61 42 70 39 62 0a 47
120 64 71 6a 49 57 49 57 33 68 4e 72 6e 64 4e 79 61
130 4d 6f 65 72 63 51 57 32 42 32 49 30 34 65 52 73
140 65 79 79 41 75 6b 6c 55 31 35 64 33 37 55 73 36
150 56 71 6f 43 32 6c 70 47 41 67 68 32 4f 47 54 0a
160 70 75 65 70 42 34 5a 5a 47 66 30 4b 6f 4b 57 76
170 59 70 35 38 7a 78 33 4a 49 75 67 43 64 46 54 76
180 4d 5a 55 4a 41 64 52 46 58 37 63 67 44 53 4d 72
190 38 63 78 64 58 45 4b 46 77 73 32 46 6f 58 48 2f
1a0 0a 72 51 49 44 41 51 41 42 0a 2d 2d 2d 2d 2d 45
1b0 4e 44 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d
1c0 2d 2d 0a
Sending private message to Bob: "Hey Bob!"
Terminating...
Alice will subscribe to Eve network service, and then immediately sends her public key to Bob. After this operation she will receive Bob public key, which will be used to initialize another cryptographic descriptor for public key encryption using the received key. Immediately after this step a simple message is encrypted and dispatched, using Eve, to Bob.
Now, output on Eve console at this time is:
Received 0 bytes --> Alice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000
Alice on port 61430
Received 451 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49
010 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49
020 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41
030 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43
040 67 4b 43 41 51 45 41 35 36 6b 6f 37 36 44 4c 75
050 35 46 55 36 56 52 64 51 42 56 78 0a 64 4f 58 50
060 63 6e 36 79 31 4d 6e 2b 63 4f 47 75 4e 48 65 79
070 76 36 39 38 2b 2b 33 4b 42 7a 58 77 47 57 48 6d
080 77 73 62 75 71 56 51 6b 2b 77 58 33 33 48 55 32
090 56 38 61 63 76 4b 53 6b 2f 78 48 63 0a 68 6b 79
0a0 72 70 59 66 53 6b 78 6a 41 70 6a 47 6c 51 46 70
0b0 31 31 6c 4e 4a 39 7a 37 6b 34 6d 47 72 59 5a 74
0c0 78 2f 70 45 32 79 47 70 74 65 6f 69 78 6e 72 49
0d0 51 6f 52 52 58 77 69 6b 54 74 69 65 4b 0a 79 2f
0e0 42 50 6e 63 67 79 30 42 53 47 55 67 4a 67 37 43
0f0 68 76 66 4d 65 43 57 36 52 4e 50 62 4e 55 41 67
100 48 31 38 75 45 74 42 58 4e 75 63 49 4a 56 58 48
110 44 76 79 6d 66 70 58 47 36 69 34 43 72 39 0a 4a
120 6e 41 46 75 48 41 42 63 6e 75 35 6a 75 4e 37 61
130 58 31 77 4d 69 4b 76 77 58 4f 4c 63 41 56 39 79
140 33 33 32 34 54 69 70 4b 79 66 62 50 67 71 39 73
150 59 6f 67 69 2b 6d 42 71 6b 73 5a 6f 78 65 46 0a
160 2f 6f 47 47 67 32 52 4e 48 59 69 4f 37 4c 51 47
170 77 51 65 66 57 45 62 64 6b 6f 4b 4d 65 4f 75 2b
180 48 58 71 70 4b 63 6c 46 5a 72 52 35 6e 52 4c 6a
190 39 71 59 58 6a 72 47 2f 36 4f 53 6a 59 51 66 56
1a0 0a 57 51 49 44 41 51 41 42 0a 2d 2d 2d 2d 2d 45
1b0 4e 44 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d
1c0 2d 2d 0a
Received 451 bytes --> ToAlice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49
010 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49
020 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41
030 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43
040 67 4b 43 41 51 45 41 79 62 4a 6c 6d 62 51 64 71
050 6d 4e 62 45 4a 6e 37 57 67 6c 5a 0a 4b 53 52 6a
060 58 51 36 77 47 43 76 74 50 69 6c 48 65 32 2f 6f
070 71 70 54 38 50 36 53 4d 50 79 42 48 68 47 69 67
080 6b 70 75 45 48 34 50 34 65 35 36 72 74 66 2f 51
090 73 75 5a 70 57 68 79 63 64 49 65 61 0a 6f 69 73
0a0 58 64 63 69 56 33 66 46 6d 4a 56 38 45 6c 33 65
0b0 70 57 75 77 64 4f 41 66 79 70 54 4d 42 69 71 70
0c0 38 6d 32 64 6b 41 51 70 57 63 36 66 5a 55 57 53
0d0 59 54 6c 36 39 5a 6a 48 56 39 39 55 56 0a 35 6d
0e0 4c 4f 55 30 4a 46 50 59 44 71 6c 4c 70 74 55 59
0f0 4c 38 4f 53 33 48 51 6e 4f 4f 56 6d 64 6d 65 4a
100 2b 34 68 50 72 31 39 55 48 6f 39 66 64 33 39 2f
110 76 74 62 6a 7a 4a 33 35 47 61 42 70 39 62 0a 47
120 64 71 6a 49 57 49 57 33 68 4e 72 6e 64 4e 79 61
130 4d 6f 65 72 63 51 57 32 42 32 49 30 34 65 52 73
140 65 79 79 41 75 6b 6c 55 31 35 64 33 37 55 73 36
150 56 71 6f 43 32 6c 70 47 41 67 68 32 4f 47 54 0a
160 70 75 65 70 42 34 5a 5a 47 66 30 4b 6f 4b 57 76
170 59 70 35 38 7a 78 33 4a 49 75 67 43 64 46 54 76
180 4d 5a 55 4a 41 64 52 46 58 37 63 67 44 53 4d 72
190 38 63 78 64 58 45 4b 46 77 73 32 46 6f 58 48 2f
1a0 0a 72 51 49 44 41 51 41 42 0a 2d 2d 2d 2d 2d 45
1b0 4e 44 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d
1c0 2d 2d 0a
Received 256 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 66 01 3a 04 35 a1 87 4b 13 a0 92 61 4b 5c ae bc
010 a7 fe fc ed f5 03 a1 50 ef c1 3e aa a7 65 cf 70
020 77 7a 1e da 62 cb ce 47 86 fb 90 62 9e 4f 99 d9
030 03 53 b3 9d e9 bb 48 28 57 ab 2d 4b c3 58 3e 7c
040 27 ed 15 e3 a3 6c 29 52 d0 4f 86 e0 18 28 77 d5
050 0c 6e d7 80 e5 80 28 e7 b2 0e 57 8d 2a 44 94 84
060 83 c2 80 7f 17 97 b1 ec 85 e4 22 e0 69 b1 b1 e3
070 75 8c b0 56 81 96 90 c6 7e b6 77 50 e8 09 e3 d1
080 32 31 a1 ad 33 d8 e9 e8 21 60 ac ee d7 96 eb 2a
090 7f 80 6c 93 fe 89 91 a4 f2 82 c3 21 43 cf 36 e5
0a0 46 7a 30 e7 83 1f bf 13 ad 5e ff b0 19 16 25 87
0b0 da 11 11 03 13 47 e5 b5 43 bd 79 2f 61 96 f2 a3
0c0 a6 86 ff ed 22 a0 a7 ce eb d8 61 3d 7a 46 b0 a3
0d0 9b 07 ac 67 d8 d5 bc 5e 85 49 04 fa d1 6e f4 15
0e0 73 be a2 1c 31 8f ce 3e e4 2f f1 f0 73 48 67 b9
0f0 3c ea eb dd 68 0e d8 89 6d 74 1d 46 12 16 b9 14
The first message is Alice presenting to Eve services, and then the following two messages contains the public key of Alice and Bob being exchanged (451 bytes of the PEM-format key file). The last message is the 2048-bits encrypted block of bytes which contains Alice hello.
Bob console will terminate with the following output:
Waiting for Alice message.....................DONE
Message is: Hey, Bob!
Terminating...
Man-in-the-middle attack on Asymmetric cipher Key exchange
As you probably already realized in the previous chapter, while the protocol has been simplified and is now straightforward, it is extremely vulnerable to a man-in-the-middle attack. This type of attack usually see a node in the middle of the communication faking the role of one user or another in order to decrypt, and eventually alter, the traffic which is passing by.
The attack here follow this steps:
- Alice generates a couple of asymmetric keys, one private and the other public.
She then share the key with Bob as it is.
- Mallory intercept the key and save it for later use. Then sends to Bob a fake public key which mimic the legit Alice one.
- Bob generates a couple of asymmetric keys, one private and the other public.
When he receive Alice fake public key, he will answer with his public key.
- Mallory again intercept the key and save it for later use. Then sends to Alice a fake public key which mimic the legit Bob one.
- Alice encrypts the private message for Bob using the key she belive is from Bob.
After the operation is done she send it to Bob.
- Mallory now decrypts everything using Bob fake private key, print the message and encrypt it using the real Bob public key. Then send the message encrypted with the legit key to Bob.
- Bob decrypts the message and do not realize that it has been intercepted and decrypted. Not even Alice realize that an actor in the middle messed with the communication. Mallory could have altered the message with a different order/request without any of the endpoint of the communication realizing that they have been intercepted.
This does not mean that key exchange with Asymmetric chipers is not safe to perform, but means that some additional mechanism (like Authentication, coming soon) are necessary to correctly perform the operation, or at least to detect the tampering.
Man-in-the-middle attack example
Switch again folder to match Basic/KeyExchange/MITM. Inside this directory you will find a copy of Bob and Alice applications using asymmetric ciphers. Nothing changed for the two users, since this attack is completely transparent for the protocol interactions. During this example we will concentrate only on Mallory console, since Alice and Bob one wont have any difference from the previous ones.
If you start Mallory what will you see will be the following:
Creating cryptographic contexts...
1/4 Loading fake Alice private key........DONE
2/4 Loading fake Alice public key.........DONE
3/4 Loading fake Bob private key..........DONE
4/4 Loading fake Bob public key...........DONE
The application expects Alice and Bob to connect, and so prepares a couple of private/public key that will be used to exchange the legit ones. It then waits for Bob and Alice to come online. Bob start wont trigger anything since it will be Alice the one which will start the communication and the public key exchange.
Once Alice is run, Mallory console will trace the public keys exchange, provide fake ones and translates the encryption from the one using fake key to the one using leti one. At the end of the operations his console will have the following text:
Received 0 bytes --> Bob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000
Bob on port 50600
Received 0 bytes --> Alice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000
Alice on port 50601
Received 451 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49
010 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49
020 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41
030 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43
040 67 4b 43 41 51 45 41 35 36 6b 6f 37 36 44 4c 75
050 35 46 55 36 56 52 64 51 42 56 78 0a 64 4f 58 50
060 63 6e 36 79 31 4d 6e 2b 63 4f 47 75 4e 48 65 79
070 76 36 39 38 2b 2b 33 4b 42 7a 58 77 47 57 48 6d
080 77 73 62 75 71 56 51 6b 2b 77 58 33 33 48 55 32
090 56 38 61 63 76 4b 53 6b 2f 78 48 63 0a 68 6b 79
0a0 72 70 59 66 53 6b 78 6a 41 70 6a 47 6c 51 46 70
0b0 31 31 6c 4e 4a 39 7a 37 6b 34 6d 47 72 59 5a 74
0c0 78 2f 70 45 32 79 47 70 74 65 6f 69 78 6e 72 49
0d0 51 6f 52 52 58 77 69 6b 54 74 69 65 4b 0a 79 2f
0e0 42 50 6e 63 67 79 30 42 53 47 55 67 4a 67 37 43
0f0 68 76 66 4d 65 43 57 36 52 4e 50 62 4e 55 41 67
100 48 31 38 75 45 74 42 58 4e 75 63 49 4a 56 58 48
110 44 76 79 6d 66 70 58 47 36 69 34 43 72 39 0a 4a
120 6e 41 46 75 48 41 42 63 6e 75 35 6a 75 4e 37 61
130 58 31 77 4d 69 4b 76 77 58 4f 4c 63 41 56 39 79
140 33 33 32 34 54 69 70 4b 79 66 62 50 67 71 39 73
150 59 6f 67 69 2b 6d 42 71 6b 73 5a 6f 78 65 46 0a
160 2f 6f 47 47 67 32 52 4e 48 59 69 4f 37 4c 51 47
170 77 51 65 66 57 45 62 64 6b 6f 4b 4d 65 4f 75 2b
180 48 58 71 70 4b 63 6c 46 5a 72 52 35 6e 52 4c 6a
190 39 71 59 58 6a 72 47 2f 36 4f 53 6a 59 51 66 56
1a0 0a 57 51 49 44 41 51 41 42 0a 2d 2d 2d 2d 2d 45
1b0 4e 44 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d
1c0 2d 2d 0a
Received 451 bytes --> ToAlice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49
010 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49
020 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41
030 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43
040 67 4b 43 41 51 45 41 79 62 4a 6c 6d 62 51 64 71
050 6d 4e 62 45 4a 6e 37 57 67 6c 5a 0a 4b 53 52 6a
060 58 51 36 77 47 43 76 74 50 69 6c 48 65 32 2f 6f
070 71 70 54 38 50 36 53 4d 50 79 42 48 68 47 69 67
080 6b 70 75 45 48 34 50 34 65 35 36 72 74 66 2f 51
090 73 75 5a 70 57 68 79 63 64 49 65 61 0a 6f 69 73
0a0 58 64 63 69 56 33 66 46 6d 4a 56 38 45 6c 33 65
0b0 70 57 75 77 64 4f 41 66 79 70 54 4d 42 69 71 70
0c0 38 6d 32 64 6b 41 51 70 57 63 36 66 5a 55 57 53
0d0 59 54 6c 36 39 5a 6a 48 56 39 39 55 56 0a 35 6d
0e0 4c 4f 55 30 4a 46 50 59 44 71 6c 4c 70 74 55 59
0f0 4c 38 4f 53 33 48 51 6e 4f 4f 56 6d 64 6d 65 4a
100 2b 34 68 50 72 31 39 55 48 6f 39 66 64 33 39 2f
110 76 74 62 6a 7a 4a 33 35 47 61 42 70 39 62 0a 47
120 64 71 6a 49 57 49 57 33 68 4e 72 6e 64 4e 79 61
130 4d 6f 65 72 63 51 57 32 42 32 49 30 34 65 52 73
140 65 79 79 41 75 6b 6c 55 31 35 64 33 37 55 73 36
150 56 71 6f 43 32 6c 70 47 41 67 68 32 4f 47 54 0a
160 70 75 65 70 42 34 5a 5a 47 66 30 4b 6f 4b 57 76
170 59 70 35 38 7a 78 33 4a 49 75 67 43 64 46 54 76
180 4d 5a 55 4a 41 64 52 46 58 37 63 67 44 53 4d 72
190 38 63 78 64 58 45 4b 46 77 73 32 46 6f 58 48 2f
1a0 0a 72 51 49 44 41 51 41 42 0a 2d 2d 2d 2d 2d 45
1b0 4e 44 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d
1c0 2d 2d 0a
Received 256 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 94 e6 b6 06 e2 18 3f 87 57 32 a4 63 1e 5d 41 13
010 4c c3 b0 95 8a 8d 37 12 bf 15 17 7d d6 d9 0e 16
020 e1 ef 82 d5 b8 e6 67 00 e3 c3 89 94 68 fc 59 53
030 8a 16 80 4f fc a3 dd 81 7a 3c 90 87 d0 5c 88 1f
040 87 52 2d 3b c6 87 3e 50 ed 05 df e6 b4 01 ae 09
050 ab ee e2 a4 db 9a bf be 5c 2c 12 d8 11 43 d8 b7
060 68 5b 2b fd 6b f2 bf df 19 9c 77 6c ac 0e 42 46
070 a1 c6 31 7f ef 4b c2 26 b9 32 10 4c 98 ae af 57
080 db 3a 4b a6 f7 94 9e be 01 8c ab 79 f9 bf b1 11
090 f6 2f 03 d4 5c 5e e9 3a 2f a0 ef f0 47 4f a8 8e
0a0 22 b5 86 4e f8 be 77 2a fc 51 2c f0 6e a1 1e 3e
0b0 7d 69 4a c8 58 68 5b 91 a9 8e 7c 79 10 bf 91 d6
0c0 a4 06 4c 63 02 06 ef 57 30 d5 26 76 12 ef 4e d0
0d0 da ea 3a f4 88 2c 39 ec b1 47 75 b2 2b 04 eb 71
0e0 09 48 a9 5b ec 94 99 99 a1 77 4c 25 da 10 4c d8
0f0 c7 05 4c cd a5 f9 94 b8 1a e2 f8 9a 84 a4 cb 26
Sent by Alice: Hey, Bob!
You can realize that the public key have been changed by looking the key received by Alice and Bob. when Alice finally send her message to Bob, now Mallory is able to decrypt it and show to you its secret content on the screen.
Key exchange using Asymmetric ciphers and Interlocked protocol
It is still possible to perform Asymmetric Key Exchange and realize the attack if additional security elements, like Authentication, are introduced in the communication. If you have no such tools what you can do it trying to mitigate the attack and make harder and harder for Mallory to fake Alice of Bob identity.
Interlocked protocols works because they send just a part of the message, which is not possible to decrypt alone, but must be put all together. The trick here is that Mallory needs to perfectly match the behavior of both Alice and Bob (just injecting his own fake keys is not enough), and cannot just operate on the data which arrives on the channels.
The protocol behaves as follows:
- Alice generates a couple of asymmetric keys, one private and the other public.
She then share the key with Bob as it is.
- Bob generates a couple of asymmetric keys, one private and the other public.
When he receive Alice public key, he will answer with his public key.
- Alice, who received the Public key form Bob, encrypts a message using such key, but send only a portion (one out of "n" pieces) of it (half of it in the example).
- Bob receive the portion of the message and prepares an answer, encrypting it using received Alice public key. He also send just a portion (one out of "n" pieces) of the message (again half of the message in the provided example).
- Both Alice and Bob continue sending a piece at time until the entire message is sent.
- Now that the entire message is in both Alice and Bob hands, they start to decrypt it and evaluate the content to see if something nasty has happened.
At a first sight it does not seems that the protocol provides at all a way to avoid main-in-the-middle attacks, but you have to consider that the pieces sent one by one are not decryptable by Mallory. For a successful decryption Mallory has to store the entire message from Alice, decrypt it and send it to Bob. But Bob wont send anything until it has received an equal amount of pieces from Alice.
What Mallory has to do here is to commit something to Bob, trying then faking not only the key, but also Alice behavior. This is a way more difficult task to perform. Sending different messages has also an additional effect: now the transmission take a total different direction than the one intended to be by the original Alice and Bob.
Interlocked key exchange example
Change directory to match Basic/KeyExchange/Interlocked directory. As for all the other examples compile it in order to obain Mallory as man-in-the-middle attacker, and Alice and Bob application with interlocked functionalities.
Running Mallory will lead to the same behavior as for the MITM version. The malicious service provider will passively listen for incoming connection by Bob and Alice, and then it will try to share with them fake keys for public encryption of the messages.
Creating cryptographic contexts...
1/4 Loading fake Alice private key........DONE
2/4 Loading fake Alice public key.........DONE
3/4 Loading fake Bob private key..........DONE
4/4 Loading fake Bob public key...........DONE
Running Bob will have almost no effects, but running Alice will reveal now a different results in Mallory console:
Received 0 bytes --> Bob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000
Bob on port 53076
Received 0 bytes --> Alice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000
Alice on port 55762
Received 451 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49
010 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49
020 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41
030 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43
040 67 4b 43 41 51 45 41 79 34 4b 57 77 62 4d 71 65
050 74 70 68 2f 7a 2f 4d 4c 73 4a 4b 0a 44 4e 4d 58
060 66 48 6c 36 53 65 42 68 65 6e 64 72 55 62 37 4c
070 74 59 2b 73 63 4b 38 43 45 36 59 56 66 49 6c 4b
080 53 70 58 6a 36 48 58 62 45 59 6a 57 2f 51 72 35
090 41 44 47 76 5a 38 34 43 71 39 4d 6a 0a 78 6b 57
0a0 4d 4d 39 50 32 74 53 43 66 75 49 37 47 4a 62 6e
0b0 38 47 47 67 41 38 2f 38 4f 70 4e 57 35 30 6d 51
0c0 6b 6d 41 58 4b 68 73 51 59 4d 34 4d 5a 68 66 38
0d0 4e 46 4f 49 6a 62 32 4c 77 48 4c 64 4f 0a 36 34
0e0 36 6e 70 6a 45 71 4c 6c 57 4a 54 65 6f 4b 70 59
0f0 44 67 6d 31 36 73 59 31 52 4e 62 39 6e 73 37 74
100 51 71 34 6b 2f 55 6e 31 6f 4d 74 74 38 2f 70 6a
110 79 58 53 38 67 4a 79 42 6b 41 51 34 41 79 0a 56
120 75 4f 65 52 70 51 42 78 44 4f 74 73 45 31 72 34
130 35 31 4e 78 62 44 6d 59 34 49 51 56 4d 64 49 6a
140 61 61 51 49 41 35 6f 2f 34 33 6a 6d 62 65 38 63
150 30 54 37 42 45 6d 63 6e 62 4c 48 4e 63 54 72 0a
160 34 4b 35 67 51 73 42 37 6f 6c 44 42 79 44 69 76
170 6a 74 67 79 65 6a 4b 49 42 6e 77 32 4e 4f 4d 4d
180 51 6f 4f 46 51 6d 6a 73 39 39 6a 65 47 79 78 44
190 35 66 36 54 67 4c 46 56 68 57 62 6e 55 43 57 7a
1a0 0a 2f 77 49 44 41 51 41 42 0a 2d 2d 2d 2d 2d 45
1b0 4e 44 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d
1c0 2d 2d 0a
Received 451 bytes --> ToAlice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49
010 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49
020 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41
030 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43
040 67 4b 43 41 51 45 41 79 71 53 76 5a 79 62 6f 72
050 30 58 58 72 65 4e 44 51 70 35 69 0a 72 2f 61 6f
060 6c 58 61 33 69 4e 63 36 49 45 72 66 5a 43 6e 61
070 46 38 42 53 50 41 36 75 37 5a 31 71 68 4d 2b 45
080 58 46 52 45 74 63 74 62 70 37 2b 63 2b 73 52 48
090 6e 4c 55 78 6d 6d 5a 58 36 73 49 7a 0a 4d 4a 4f
0a0 6b 38 6a 68 46 61 50 51 6e 38 62 4f 70 46 48 6c
0b0 66 36 42 41 61 69 70 2b 4f 39 7a 5a 51 39 38 4e
0c0 6f 68 43 78 51 45 45 46 57 41 69 51 35 66 32 79
0d0 70 67 6e 44 63 66 37 4f 66 5a 64 58 74 0a 77 2f
0e0 58 42 79 55 6a 55 57 2f 79 39 6f 47 75 33 30 53
0f0 72 63 6f 79 76 30 36 50 2b 62 51 5a 2f 37 75 75
100 34 6c 42 72 70 66 41 61 38 46 45 7a 42 6b 68 61
110 53 6f 44 68 53 55 47 62 34 37 6b 45 33 42 0a 6d
120 79 57 57 51 47 68 61 53 4e 57 2f 69 38 2f 67 55
130 30 43 52 77 4c 55 31 51 58 4e 63 57 64 70 50 30
140 31 45 63 4e 47 63 71 75 5a 77 68 6f 4b 35 66 65
150 50 67 31 39 38 42 2f 75 67 2b 77 74 6e 6a 37 0a
160 4f 32 4c 53 52 33 6a 48 4b 50 48 39 47 34 69 41
170 61 48 6b 62 53 78 46 33 67 7a 75 73 37 42 76 6c
180 6b 4f 67 64 36 4a 73 75 39 35 4c 38 50 77 55 55
190 7a 35 44 72 6f 4f 77 48 78 76 72 71 30 68 7a 6e
1a0 0a 53 51 49 44 41 51 41 42 0a 2d 2d 2d 2d 2d 45
1b0 4e 44 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d
1c0 2d 2d 0a
Received 128 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 3e f1 34 e8 1a 0c 28 68 f5 1b 2e 12 bc a2 04 61
010 50 4f 7e 3a 50 3e 37 e1 66 0f fd 21 98 3e 77 ee
020 9f e1 bb 40 e9 95 d6 9d c7 6e b7 81 16 55 5d 15
030 10 e9 1a 4a b7 7e 2c be 24 98 a1 e7 8a e9 8a e0
040 87 a5 82 96 c9 b5 04 44 21 98 42 d7 ec 8b 9b 53
050 ee 8b 74 d5 9e a5 f8 f7 ac 91 51 37 68 41 27 5e
060 15 9a fa c7 c8 0b f5 15 71 2f d8 6e 32 4e 7c 57
070 92 4f 0a cc 7c d0 59 d3 33 06 18 d2 3e f0 ed 42
Problem decrypting traffic towards Bob!
Received 128 bytes --> ToAlice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 01 43 c2 be b0 02 29 83 0a 48 75 74 28 99 0d e0
010 01 73 17 27 1a b4 fd 12 0c f4 1c ea 54 93 66 03
020 f7 a7 d7 be 44 75 d7 41 ba 98 d6 d4 e0 93 4d eb
030 9e 41 5b cb 8f d8 1c fb 6a 54 48 c7 d9 70 66 21
040 cd ed 65 21 21 c4 a2 57 85 a1 bc 17 d0 a7 4a a5
050 7b 74 09 67 4d 98 34 5e 07 f1 9f 6f 0b b0 e4 56
060 0e f5 ef d5 7b f3 bb 84 f5 13 cb ad 85 35 d5 c3
070 09 86 86 17 46 9c 4e 5a 62 d1 2b c4 af cd 0e 43
Problem decrypting traffic towards Alice!
Received 128 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 86 3c f9 f0 24 23 93 01 9d 44 e1 f6 58 f3 bd 98
010 f7 d7 81 93 33 91 78 01 52 e6 de 90 b6 65 ce fb
020 30 5f 59 1f a5 e8 8c ce 20 a2 54 65 3a b8 54 2e
030 e6 ac 23 20 ad da 2c 90 6a 5a a9 58 2d 14 b3 c9
040 dc 4a 5c b7 ae 3a 4a 05 fb 3b 6f e7 cd 9f 30 08
050 90 54 88 1a 76 2c 68 81 6a 8e fb 76 5a 71 76 9b
060 4f 76 03 34 e1 e8 30 6c 62 58 07 a4 31 8f 9e 7f
070 75 f8 68 1e 40 fe 9e 4e 27 df 0e ac bd b1 04 1b
Problem decrypting traffic towards Bob!
Received 128 bytes --> ToAlice
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 d1 c8 06 3c c0 3d 4d 2c c7 6d b3 a5 3e 4c ac 18
010 b0 a8 a5 f4 1a 40 64 cd a9 ac f8 2f a2 28 25 39
020 5f 89 9c 72 59 ab f5 2d 52 46 88 d0 4a e1 fe 95
030 bd e7 62 e6 d4 a3 50 6a 52 12 dd ef 78 2d 32 c1
040 3f 56 8a ad ea 5d 69 f7 45 bf 2c 46 93 b8 57 45
050 93 d3 71 2d 23 8a 35 fd 03 56 dc 61 e7 10 78 cb
060 d7 b8 bd dd ec 98 a7 6d d8 1b 53 77 d3 18 ed de
070 98 97 ac 2a 9f d6 97 51 18 4e 13 d6 c8 24 81 04
Problem decrypting traffic towards Alice!
In this case Mallory has no idea what kind of messages Alice and Bob will exchange between themselves, but commited to them a fake public key, so it has to take care of the messages passing by. As you can see the key exchange stage is performed without much difference, but now Alice and Bob send only part of the messages, and not the entire ones.
This information cannot be decrypted without the other part, but something must be sent to Bob to trigger an answer. As a faulty behavior (useful for this example), if Mallory cannot decrypt the message he sends it to the destination without modifications. This happens for all the four pieces of the two messages exchanged between Alice and Bob.
The result of this operation, since such messages where encrypted using fake public key, if to obtain an unreadable message, which will also trigger a notification that something nasty is happening at network level. On Alice console in fact we can see the following report:
Basic Cryptography: Interlocked protocol
Setting up cryptographic contexts...
1/2 Loading private key...................DONE
2/2 Loading public key....................DONE
Initializing network..........................DONE
Presenting to network provider................DONE
Preparing Bob context...
1/3 Requesting Bob public key.............DONE
2/3 Receiving the key.....................DONE
3/3 Preparing Bob context.................DONE
Key received from Bob:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49
010 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49
020 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41
030 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43
040 67 4b 43 41 51 45 41 71 58 64 71 65 51 67 37 48
050 2b 37 51 4d 31 30 6f 37 58 6a 37 0a 65 2f 34 44
060 66 69 56 6a 6e 58 43 65 54 65 44 56 46 31 2b 55
070 66 32 39 6d 68 6c 46 70 46 34 38 36 50 4c 63 38
080 4d 6d 56 6a 33 76 63 6e 72 75 64 76 57 55 45 6f
090 55 52 67 71 56 4e 30 74 64 71 37 46 0a 45 7a 61
0a0 72 71 31 54 76 6d 75 50 33 2f 6f 71 5a 43 66 77
0b0 36 7a 45 45 78 45 53 30 2b 50 39 43 71 58 58 35
0c0 77 73 52 79 54 62 36 6a 79 6f 50 59 47 54 31 64
0d0 71 6c 57 4d 72 37 34 79 50 5a 4c 43 44 0a 6f 72
0e0 44 36 4a 31 78 62 6b 42 56 6c 6d 6a 4a 37 4f 46
0f0 2f 50 4d 62 37 38 51 63 49 52 37 66 68 53 2f 53
100 75 59 4c 35 59 4c 34 30 4c 48 50 34 5a 52 71 31
110 52 6c 70 34 39 64 72 74 47 53 67 44 58 62 0a 45
120 51 4b 2b 72 45 43 66 39 58 4d 35 59 35 33 67 66
130 6a 73 51 65 76 41 76 6f 58 41 68 45 49 39 65 53
140 4a 34 37 55 59 69 78 58 53 39 44 38 51 59 2f 78
150 51 43 65 74 4f 37 36 52 64 6b 62 69 65 37 68 0a
160 79 71 63 45 38 76 6a 4f 34 2b 71 4f 47 4a 45 4d
170 6a 2b 32 78 72 6c 4c 43 33 2f 58 57 72 37 66 54
180 33 42 45 57 51 5a 6f 6a 4b 6d 4c 43 78 58 58 36
190 50 58 4f 58 37 35 68 2b 64 6a 46 4f 35 59 67 33
1a0 0a 31 51 49 44 41 51 41 42 0a 2d 2d 2d 2d 2d 45
1b0 4e 44 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d
1c0 2d 2d 0a
Sending private message to Bob: "Hey Bob!"
Processing Bob answer.........................FAILED; error while processing
This means that we cannot decrypt with our private key (which never left our computer) the message Bob should have encrypted with our public one; clearly a trace of the alteration of the communication.
Key Exchange with Symmetric and Asymmetric chipers
Since every cryptographic cipher has its pros and cons, in the real world they are usually combined together to gain the best from both the methods. Asymmetric ciphers are usually slow, but independent to a central authority that act as a single point of failure. On the other side Symmetric chipers are lightweight, and provides the best performance in terms of time and space (faster and with smaller keys).
Using both the ciphers results in the following protocol:
- Alice generates a couple of asymmetric keys, one private and the other public.
She then share the key with Bob as it is.
- Bob generates a couple of asymmetric keys, one private and the other public.
When he receive Alice public key, he will answer with his public key.
- Alice now creates a new symmetric session key, then encrypts it with Bob public key and finally send it to Bob.
- Bob receive the key and decrypt the message. He then obtain the symmetric session key that can be used to support the further communication between him and Alice.
- The communication now proceed with Symmetric key ciphers.
Now costly asymmetric cipher operations are used for the initial setup of the communication, provided that additional mechanisms like authentication or the use of a PKI (Public Key Infrastructure) grants that the identity of the message is trusted. Once this step is done, all the following communication is performed using the Symmetric cipher, which grants better performances. For security reason the session key can be renewed periodically to disrupt the ability of a eavesdropper of intercepting and guess/compute the used key.
Asymmetric and Symmetric ciphers example
Change the directory to match Basic/KeyExchange/KeyAndMessage directory under the project sources. As any other folder, you can directly make that single prototype or build it altogether with all the others by calling the make in the root directory.
During this experiment you will have a passive Eve providing the service to Alice and Bob. She will silently monitor the data as it flow through the required destination. Alice here is assumed to have acquired somehow the public key of Bob, either with direct communication with Bob (see previous chapters) or through the use of a PKI.
Run eve first, then Bob, and finally Alice. Bob wil sit down listening for incoming session key from Alice, which is exchanged in the first message encrypted using Asymmetric cipher technologies. Eve will notice this by taking into account the size of the message exchanged and guess that such a chiper has been used.
Received 256 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 4d 6c 7b a1 b5 46 a8 26 51 7c 11 cc 29 ec 76 0b
010 90 e1 a3 0a 84 7b 21 eb 54 96 ee 57 4d 1e ab 42
020 a7 9f d6 6f 41 5d f6 2b 4d 3d 4f c7 53 ec aa bf
030 f2 41 4f d1 fb 12 f9 ef 94 c1 fe b4 45 aa dd fa
040 32 1c 04 eb 80 7b 75 a3 61 50 cc b5 74 2a 48 79
050 48 7d c1 eb c4 15 b6 d0 9a 4f 3e a4 9b 4d d9 c7
060 99 aa ab 7b 6a 6b a7 cd 25 16 36 e3 dd 4c 1d 85
070 b2 de 23 d0 f9 b5 3d d0 8c d0 79 ec 49 ec 95 a1
080 c6 ea 8e e7 e1 c2 57 e1 05 f5 7d d1 e3 f8 6d 10
090 c9 28 8a e4 ab 15 d4 54 07 e9 63 74 53 a7 0c 93
0a0 45 3a 4f dd 9f e9 0b 11 4f de 14 14 06 b1 24 a3
0b0 27 ec ad db 8e e6 ad f1 1e 87 c6 1a 76 21 86 52
0c0 0e 81 0e 72 81 dd 66 8b 89 5f f9 5d 0c 02 18 33
0d0 4b 80 b1 05 5c 73 e5 76 bd 3a 28 98 ce f6 9d e9
0e0 bb 31 d1 bb 49 fc 75 f1 f0 0f d0 c5 4f 5d 32 5b
0f0 d9 94 e0 2d 55 a2 e0 48 15 e4 d4 a3 a3 46 91 c5
After this initial transmission, which will contains the symmetric key for the following messages, Alice swaps technology and start communicating using AES-256. The following message intercepted and forwarded by Eve is:
Received 32 bytes --> ToBob
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000 2f 73 cf b0 fc 46 93 bd 65 d9 92 b0 7c d4 8c cc
010 ca e9 b7 03 90 93 2d af 6d 3d 90 50 69 6b 25 f4
On Bob side, he will decrypt the initial message using his private key. since we assume the public key has been correctly and safely exchanged, if he's not able to decrypt this it assumes that an alteration took place. After having received the session information, he setup a Symmetric cipher descriptor and start to use it to process following incoming messages from Alice.
BasicCryptography: Key and Message exchange
Setting up cryptographic contexts...
1/2 Loading Bob private key...............DONE
2/2 Loading Bob public key................DONE
3/3 Loading Alice public key..............DONE
Initializing network..........................DONE
Presenting to network provider................DONE
Waiting for Alice session.....................DONE
Alice-Bob Key: 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31
Input vector: 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35
Getting Alice message.........................DONE
Message is: Hey Bob!
Terminating...
