Knowledge

In the application the simulation of the TLS protocol is given. The visualization contains a basic simulation of the handshake protocol and data transmission protocol of TLS 1.2.

1. The Handshake

Protocol

For the client and the server to be able to both read the data packages, they both need to agree on an encryption key. Thereby a MAC (Message Authentication Code) is used to ensure package integrity and a compression algorithm to compress the data. The process in which both server and client agree on the different algorithms to use is called a handshake and is described by the handshake protocol. After the handshake is completed, data can be sent over the secured connection using the agreed upon encryption key, compression method and MAC algorithms.

In the application a client (c) and a server (s) are communicating with each other. As can be seen in the visualisation in the initial state both the client and server already know everything about their own state. For example the client knows the MAC algorithms RSA and MD5 while the server only knows the algorithm MD5. The client and server also know their own installed version of the TLS protocol. The enumeration below describes the process between the client and the server.

As can be seen, in the first step, a package is being sent from the client to the server. This package contains all information about what the client knows and is called the “client_hello” message. When this package arrives at the server side, the server will add this knowledge to its knowledge base.
In our case, the client sends an empty session_id to the server, so the server will now generate a new session_id which is used to identify this certain connection.
After that, the server will send back a “server_hello” package in which the server tells the client the parameters on which the server agrees upon. This will be the algorithm with which the key is going to be exchanged, the session identity etc.
In the case of RSA, the server will generate a random public key and send this to the client within the “server_certificate” package. After this a “server_hello_done” message is sent. Now the server waits for the client to respond with the premaster secret message.
The client will generate a premaster secret which is encrypted by using the public key that was sent by the server. The encrypted messages is called the client_key_exchange message and is sent to the server. Now both sides have the same premaster secret and client and server random numbers. Client and server random numbers have been negotiated in the client_hello and server_hello message.
Based on these parameters both the client and server will generate the same master secret.
The changeCipherspec message is sent by both client and server. It is first send by the client. The client then sends the “client_finished” message. Now the server sends a changeCipherspec message to the client and then a “server_finished” message.
The client and the server now both know that the security parameters that they just negotiated have been agreed upon by both sides. The handshake protocol is now finished.
Based on the parameters they agreed upon the communication parameters are calculated by both server and client. These parameter exist of a write key, a MAC key and initialization vectors.
In the succeeding steps, data is sent over the just setup secure connection, as explained in the section below.
After all the data is sent, the connection is closed by sending a alert_close_notify message.

2. Application data protocol

The application data that is being communicated by both the client and the server is carried by the TLS record layer. This is the same layer on which the handshake protocol functions. Messages are fragmented, compressed, and encrypted based on the current connection state. They are therefore safely sent over the network between client and server. The following steps are taken when sending a message:

Messages that are being sent are fragmented into chunks containing 2^14 bytes or less.
The fragmented chunks are then compressed using the active compression algorithm. Compression is lossless, so the original message can be reconstructed.
The MAC is computed for the compressed chunk. The MAC write key, the sequence number, and of course the fragmented chunk data are used to calculate the MAC.
Encryption is done using the current encryption method. The compressed chunk together with the MAC are encrypted and sent over the unsafe line.
On the reveivers end of the line the reverse process starts.
The encrypted message is decrypted using the current encryption method.
The receiver checks the MAC for the compressed chunk.
When this check passes, the data is decompressed.
All these decompressed chunks are added together and now the receiver has the readable message which the sender sent.

3. Nesting knowledge

This chapter shows that during the handshake protocol, at most depth 5 knowledge can be obtained by both server and client about the client and server's parameters. To give a knowledge-based interpretation of the handshake protocol of TLS1.2, we will first give some definitions about our data representation and then introduce the knowledge accumulation during handshake protocol.

3.1. Data Format

In our analysis, we adopt two different kinds of representations. Understanding the difference between them is important to understand our project and the visualization on this website. Examples of the representations are as below:

“key_exchange:RSA” indicates that when it is apparent in either the client or the server's state table that they have installed the RSA algorithm for key exchange, i.e. they know how the RSA algorithm works and have allocated a large memory space to store the details of the RSA algorithm.

“Kc(key_exchange:RSA)” indicates taht the client knows how RSA works and that it can use it for key_exchange. This fact can be represented by only one or two bytes.

The difference between these two representations above is that if the server doesn't know how the RSA-protocol works and it receives "Kc(key_exchange:RSA)", it will know that the client knows it. However, the server still doesn't know how RSA works (¬Ks(key_exchange:RSA)). Would, at a later point, the server receive "key_exchange:RSA" then it will know the details of the algorithm RSA and we therefore get Ks(key_exchange:RSA).

3.2. Abbreviation for Knowledge Analysis

Many parameters play a vital role during the handshake protocol. Though, to make it clearer and more accessible for the reader, we use abbreviations for different packages of knowledge. The abbrevations all start with a capital letter and their details are as shown below:

“Client_hello” represents a package of knowledge as below:

	client_random_number:BB
	Kc(MAC_algorithm:MD5)
	Kc(MAC_algorithm:SHA)
	Kc(bulk_encryption:AES256)
	Kc(bulk_encryption:RC4)
	Kc(client_random_number:BB)
	Kc(compression:CC)
	Kc(key_exchange:DH)
	Kc(key_exchange:RSA)
	Kc(protocol_version:3.3)

“Server_hello” represents a package of knowledge as below:

	server_random_number:EE
	session_id:8
	Ks(MAC_algorithm:SHA)
	Ks(bulk_encryption:AES256)
	Ks(compression:CC)
	Ks(key_exchange:RSA)
	Ks(protocol_version:3.3)
	Ks(server_random_number:EE)
	Ks(session_id:8)

“Server_certificate” represents a package of knowledge as below:

	Identity:server
	Server_public_key:FF
	Ks(Identity:server)
	Ks(Server_public_key:FF)

“Client_key_exchange” represents a package of knowledge as below:

	Pre_master_secret:AA
	Kc(Pre_master_secret:AA)

3.3. Knowledge Accumulation for Handshake Protocol

Before any communication has taken place, the state tables of client and server indicate their respective initial states. For example, in the client’s state table, “protocol_version:3.3” indicates that the client has TLS 1.2 installed, it therefore knows how TLS 1.2 works. “Kc(protocol_version:3.3) indicates that the client knows TLS 1.2. This knowledge can be sent using the Client_hello.

While, for the server’s state table, we observe that it supports both version 3.2 and version 3.3. During the communcation the server and client will decide which version they use for the secured connection.

The handshake protocol starts with a Client_hello. After the server has received the Client_hello, it will know all the information inside the Client_hello, therefore we get:

	Ks(Client_hello)

Considering the details in the Client_hello, Ks(Client_hello) means

	Ks(client_random_number:BB)
	KsKc(MAC_algorithm:MD5)
	KsKc(MAC_algorithm:SHA)
	KsKc(bulk_encryption:AES256)
	KsKc(bulk_encryption:RC4)
	KsKc(client_random_number:BB)
	KsKc(compression:CC)
	KsKc(key_exchange:DH)
	KsKc(key_exchange:RSA)
	KsKc(protocol_version:3.3)

From now on, we will only use abbreviations such as Ks(Client_hello) or Kc(Server_hello) and will not unfold their details to save space.

Traditional reasoning methods will argue that since server receives Client_hello, it can also imply Kc(Client_hello) and since the server itself knows Kc(Client_hello) it can also imply KsKc(Client_hello). In our representation, however, this is incorrect. All knowledge is already inside the Client_hello package, the server does not reason about it again.

After the server received the Client_hello message, the server will send the Server_hello message to the client. The client will know the Server_hello upon its arrival and at the same time, the client can reason about this: Since the server has sent the Server_hello, it must have received the Client_hello, therefore it should know Client_hello. Based on this, the client gains the following knowledge

	Kc(Server_hello)
	KcKs(Client_hello)

After sending Server_hello, the server will send another package: Server_certificate to the client. The client will gain, again, more knowledge

	Kc(Server_certificate)

Then the server will send the message Server_hello_done to the client, since this message contains no knowledge, the client will gain no more knowledge.

Until now the client contains the following knowledge:

	Kc(Server_hello)
	KcKs(Client_hello)
	Kc(Server_certificate)

After the Server_hello_done message, the client will send package Client_key_exchange to the server. The server will know about the Client_key_exchange upon arrival and it will reason in the following way: Since the client has sent me the Client_key_exchange, it must have received the packages Server_hello and Server_certificate, so it therefore knows these two packages and the client will therefore also reason that I have successfully received Client_hello. Based on this analysis, the Server will gain the knowledge as shown below:

	Ks(Client_key_exchange)
	KsKc(Server_hello)
	KsKc(Server_certificate)
	KsKcKs(Client_hello)

After that, both the client and server will generate the master secret, the client will gain the knowledge:

	Kc(master_secret:GG)

The server will gain the knowledge:

	Ks(master_secret:GG)

Note that the master secrets they generate are the same.

After this, the client will send the two messages changeCipherSpec and Client_finish to the server. The server will reason from these two message that the client must have successfully generated the master secrete. So the server will gain:

	KsKc(master_secret:GG)

And then, the server will also send two messge: changeCipherSpec and Client_finish to the client. At first, the client will reason that the server must have successfully generated the master secret and gain the knowledge:

	KcKs(master_secret:GG)

Besides, the client will know that all their previous negotiations are successful, i.e. the server must have received and must know the Client_key_exchange, also the server must know that the client has received and knows the Server_hello and Server_certificate, also the server now knows that the client knows that the server knows the Client_hello. Therefore, the client will gain knowledge as given below:

	KcKs(Client_key_exchange)
	KcKsKc(Server_hello)
	KcKsKc(Server_certificate)
	KcKsKcKs(Client_hello)

After that, both client and server will generate their respective communication parameters: Intitial_vectors(IV), Write_key and Mac_key. All the knowledge that the client gained during the handshake protocol so far is given below:

	Kc(client_IV)
	Kc(client_write_key)
	Kc(client_mac_key)
	Kc(Server_hello)
	Kc(Server_certificate)
	Kc(master_secret:GG)
	KcKs(Client_hello)
	KcKs(master_secret:GG)
	KcKs(Client_key_exchange)
	KcKsKc(Server_hello)
	KcKsKc(Server_certificate)
	KcKsKcKs(Client_hello)

The server gains the following knowledge:

	Ks(server_IV)
	Ks(Client_hello)
	Ks(server_write_key)
	Ks(server_mac_key)
	Ks(master_secret:GG)
	KsKc(master_secret:GG)
	Ks(Client_key_exchange)
	KsKc(Server_hello)
	KsKc(Server_certificate)
	KsKcKs(Client_hello)

Notice that the client is able to gain a depth that is one level deeper than the servers depth of nested knowledge. This is because the client sends the changeCipherSpec and Client_finish immediately after it sends the Client_key_exchange, the server can not gain more knowledge from the Client_finish. While the client can reason one level of depth deeper since the Server_finish messages tell the client that the server has sucessfully received all client's messages.

Since there is one more level of depth of knowledge inside the Client_hello package, KcKsKcKs(Client_hello) with a depth of five is the maximum depth of knowledge that can be obtained during the handshake.

4. Consensus

To set up the connection both client and server need to reach an agreement. In the visualization can be seen how this is achieved. The both tables represent the world in which the client and server find themselves to be in.

Altough, both the client and server do not have to be in the same world to reach consensus, they should at least be in the same model. In the beginning of the process, the client and the server consider themselves to be in a different model since they don't know anything about each other. Then, when the client connects with the server with a client hello, the server gets information about the client therefore changing its model.

We call every changed model, a new model. There are therefore in the beginning infinitly many models since the client and server both can have an infinite set of options. Of course both client and server know what setting they have themselves but not from each other. Therefore, information has to be sent over the network. After every exchange of information worlds are deleted in either the client or the server model, creating therefore a new model.

To demonstrate how this works a simplified example is used. In this example, the client has the protocol SHA and MD5 installed, the server however only has the protocol SHA. The initial state can be seen in figure 1. In the figure cRSA indicates that the client has RSA installed. sMD5 indicates that the server has MD5 installed etc.

Figure 1

In the first step, the client will send a client_hello to the server as can be seen in figure 2.

Figure 2

Since the client_hello package describes that the client has protocol SHA and MD5 installed, the server can revise his model when it receives the package. This revised model can be seen in figure 3.

Figure 3

Now the server sends his server_hello messages as shown in figure 4.

Figure 4

After the server_hello message the client can revise his model about the world as can be seen in figure 5.

Figure 5

Of course, the model is in real life more complex but works in the same way as explained above. Altough, the client also has considerations about what the server considers possible and the server might consider the worlds that the client considers possible.

Since now both client and server know all settings about each other, they are able to compute the master secret after the client has sent the pre-master secret.