Network Security notes by IIT kanpur professor Dr. Dheeraj Sanghi

Network Security notes by IIT kanpur professor Dr. Dheeraj Sanghi.

Network Security

Data on the network is analogous to possessions of a person. It has to be kept secure from others with malicious intent. This intent ranges from bringing down servers on the network to using people's private information like credit card numbers to sabotage of major organizations with a presence on a network. To secure data, one has to ensure that it makes sense only to those for whom it is meant. This is the case for data transactions where we want to prevent eavesdroppers from listening to and stealing data. Other aspects of security involve protecting user data on a computer by providing password restricted access to the data and maybe some resources so that only authorized people get to use these,  and identifying miscreants and thwarting their attempts to cause damage to the network among other things.

The various issues in Network security are as follows :

1. Authentication: We have to check that the person who has requested for something or has sent an e-mail is indeed allowed to do so. In this process we will also look at how the person authenticates his identity to a remote machine.
2. Integrity: We have to check that the message which we have received is indeed the message which was sent. Here CRC will not be enough because somebody may deliberately change the data. Nobody along the route should be able to change the data.
3. Confidentiality: Nobody should be able to read the data on the way so we need Encryption
4. Non-repudiation: Once we sent a message, there should be no way that we can deny sending it and we have to accept that we had sent it.
5. Authorization: This refers to the kind of service which is allowed for a particular client. Even though a user is authenticated we may decide not to authorize him to use a particular service.

For authentication, if two persons know a secret then we just need to prove that no third person could have generated the message. But for Non-repudiation we need to prove that even the sender could not have generated the message. So authentication is easier than Non-repudiation. To ensure all this, we take the help of cryptography. We can have two kinds of encryption :

1. Symmetric Key Encryption: There is a single key which is shared between the two users and the same key is used for encrypting and decrypting the message.
2. Public Key Encryption: There are two keys with each user : a public key and a private key. The public key of a user is known to all but the private key is not known to anyone except the owner of the key. If a user encrypts a message in his private key then it can be decrypted by anyone by using the sender's public key. To send a message securely, we encrypt the message in the public key of the receiver which can only be decrypted by the user with his private key.

Symmetric key encryption is much faster and efficient in terms of performance. But it does not give us Non-repudiation. And there is a problem of how do the two sides agree on the key to be used assuming that the channel is insecure ( others may snoop on our packet ). In symmetric key exchange, we need some amount of public key encryption for authentication. However, in public key encryption, we can send the public key in plain text and so key exchange is trivial. But this does not authenticate anybody. So along with the public key, there needs to be a certificate. Hence we would need a public key infrastructure to distribute such certificates in the world.

Key Exchange in Symmetric Key Schemes

We will first look at the case where we can use public key encryption for this key exchange. . The sender first encrypts the message using the symmetric key. Then the sender encrypts the symmetric key first using it's private key and then using the receiver's public key. So we are doing the encryption twice. If we send the certificate also along with this then we have authentication also. So what we finally send looks like this :

Z :    Certificate_sender + Public_reciever ( Private_sender ( E_k ) ) + E_k ( M )

Here E_k stands for the symmetric key and E_k ( M ) for the message which has been encrypted in this symmetric key.However this still does not ensure integrity. The reason is that if there is some change in the middle element, then we will not get the correct key and hence the message which we decrypt will be junk. So we need something similar to CRC but slightly more complicated. This is because somebody might change the CRC and the message consistently. This function is called Digital Signature.

Digital Signatures

Suppose A has to send a message to B. A computes a hash function of the message and then sends this after encrypting it using its own private key. This constitutes the signature produced by A. B can now decrypt it, recompute the hash function of the message it has received and compare the two. Obviously, we would need the hash functions to be such that the probability of two messages hashing to the same value is extremely low. Also, it should be difficult to compute a message with the same hash function as another given message. Otherwise any intruder could replace the message with another that has the same hash value and leave the signatures intact leading to loss of integrity. So the message along with the digital signature looks like this :

Z + Private_sender ( Hash ( M ) )

Digital Certificates

In addition to using the public key we would like to have a guarantee of talking to a known person. We assume that there is an entity who is entrusted by everyone and whose public key is known to everybody. This entity gives a certificate to the sender having the sender's name, some other information and the sender's public key. This whole information is encrypted in the private key of this trusted entity. A person can decrypt this message using the public key of the trusted authority. But how can we be sure that the public key of the authority is correct ?   In this respect Digital signatures are like I-Cards. Let us ask ourselves the question : How safe are we with I-Cards? Consider a situation where you go to the bank and need to prove your identity. I-Card is used as a proof of your identity. It contains your signature. How does the bank know you did not make the I-Card yourselves? It needs some proof of that and in the case of I-Cards they contain a counter signature by the director for the purpose. Now how does the bank know the signature I claim to be of the director indeed belongs to him? Probably the director will also have an I-Card with a counter signature of a higher authority. Thus we will get a chain of signing authorities. Thus in addition to signing we need to prove that the signatures are genuine and for that purpose we would probably use multiple I-Cards each carrying a higher level of signature-counter signature pair.

So in order to distribute the public key of this authority we use certificates of higher authority and so on. Thus we get a tree structure where the each node needs the certificates of all nodes above it on the path to the root in order to be trusted. But at some level in the tree the public key needs to be known to everybody and should be trusted by everybody too.
 

Key Exchange in Symmetric Key Schemes (contd.)

In this lecture we will look at key exchange in symmetric key schemes where public key encryption cannot be used. So the encryption using public and private keys is not possible. We will see that in this scenario how do we exchange the symmetric key. The two people who are communicating do not want others to understand what they are talking about. So they would use a language which others possibly do not understand. But they have to decide upon a common language. For this the language has to be encrypted in some key which will be somehow known to the other person.Key exchange in symmetric key schemes is a tricky business because anyone snooping on the exchange can get hold of the key if we are not careful and since there is no public-private key arrangement here, he can obtain full control over the communication. There are various approaches to the foolproof exchange of keys in these schemes. We look at one approach which is as follows:-

Diffie - Hellman Key Exchange

A and B are two persons wishing to communicate. Both of them generate a random number each, say x and y respectively. There is a function f which has no inverse. Now A sends f(x) to B and B sends f(y) to A. So now A knows x and f(y) and B knows y and f(x). There is another function g such that g(x,  f(y)) = g(y, f(x)). The key used by A is g(x, f(y)) and that used by B is g(y, f(x)). Both are actually same. The implementation of this approach is described below :

1. A has two large prime numbers n and g. There are other conditions also that these numbers must satisfy.
2. A sends n, g and g^x mod n to B in a message. B evaluates (g^x mod n)^y to be used as the key.
3. B sends g^y mod n to A. A evaluates (g^y mod n)^x to be used as the key. So now both parties have the common number g^xy mod n. This is the symmetric (secret communication) key used by both A and B now. 

This works because though the other people know n, g, g^x mod n, g^y mod n but still they cannot evaluate the key because they do not know either x or y.

Man in the Middle Attack

However there is a security problem even then. Though this system cannot be broken but it can be bypassed. The situation which we are referring to is called the man-in-the-middle attack. We assume that there is a guy C in between A and B. C has the ability to capture packets and create new packets. When A sends n, g and g^x mod n,  C captures them and sends n, g and g^z mod n to B. On receiving this B sends n, g and g^y mod n but again C captures these and sends n, g and g^z mod n to A. So A will use the key (g^z mod n)^x  and B will use the key (g^z mod n)^y  . Both these keys are known to C and so when a packet comes from A, C decrypts it using A's key and encrypts it in it's own key and then sends it to B. Again when a packet comes from B, it does a similar thing before sending the packet to A. So effectively there are two keys - one operating between A and C and the other between C and B.

There must be some solution to this problem. The solution can be such so that we may not be able to communicate further ( because our keys are different ) but atleast we can prevent C from looking at the data. We have to do something so that C cannot encrypt or decrypt the data. We use a policy that A only sends half a packet at a time. C cannot decrypt half a packet and so it is stuck. A sends the other half only when it receives a half-packet from B. C has two options when it receives half a packet :

1. It does not send the packet to B at all and dumps it. In this case B will anyway come to know that there is some problem and so it will not send it's half-packet.
2. It forwards the half-packet as it is to B. Now when B sends it's half-packet, A sends the remaining half. When B decrypts this entire packet it sees that the data is junk and so it comes to know that there is some problem in communication.

Here we have assumed that there is some application level understanding between  A and B like the port number. If A sends a packet at port number 25 and receives a packet at port number 35, then it will come to know that there is some problem. At the very least we have ensured that C cannot read the packets though it can block the communication. There is another much simpler method of exchanging keys which we now discuss :  

Key Distribution Center

There is a central trusted node called the Key Distribution Center ( KDC ). Every node has a key which is shared between it and the KDC. Since no one else knows A's secret key (K_A) KDC is sure that the message it received has come from A. We show the implementation through this diagram :

When A wants to communicate with B, it sends a message encrypted in it's key to the KDC. The KDC then sends a common key to both A and B encrypted in their respective keys. A and B can communicate safely using this key. There is a problem with this implementation also. It is prone to replay attack. The messages are in encrypted form and hence would not make sense to an intruder but they may be replayed to the listener again and again with the listener believing that the messages are from the correct source. To prevent this, we can use:

• Timestamps: which however don't generally work because of the offset in time between machines. Synchronization over the network becomes a problem.
• Nonce numbers: which are like ticket numbers. B accepts a message only if it has not seen this nonce number before.

Key Distribution Centre(Recap.)

There is a central trusted node called the Key Distribution Center ( KDC ). Every node has a key which is shared between it and the KDC. Since no one else knows node A's secret key K_A, KDC is sure that the message it received has come from A. When A wants to communicate with B it could do two things:

1. A sends a message encrypted in it's key K_A to the KDC. The KDC then sends a common key K_S to both A and B encrypted in their respective keys K_A and K_B. A and B can communicate safely using this key.
2. Otherwise  A sends a key K_S to KDC saying that it wants to talk to B encrypted in the key K_A. KDC send a message to B saying that A wants to communicate with you using K_S.

There is a problem with this implementation. It is prone to replay attack. The messages are in encrypted form and hence would not make sense to an intruder but they may be replayed to the listener again and again with the listener believing that the messages are from the correct source. When A send a message K_A(M), C can send the same message to B by using the IP address of A. A solution to be used is to use the key only once. If B sends the first message K_A(A,K_S) also along with K(s,M), then again we may have trouble. In case this happens, B should accept packets only with higher sequence numbers. To prevent this, we can use:

• Timestamps which however don't generally work because of the offset in time between machines. Synchronization over the network becomes a problem.
• Nonce numbers which are like ticket numbers. B accepts a message only if it has not seen this nonce number before.

In general, 2-way handshakes are always prone to attacks. So we now look at an another protocol.

Needham-Schroeder Authentication Protocol

This is like a bug-fix to the KDC scheme to eliminate replay attacks. A 3-way handshake (using nonce numbers) very similar to the ubiquitous TCP 3-way handshake is used between communicating parties. A sends a random number R_A to KDC. KDC send back a ticket to A which has the common key to be used.

 

R_A, R_B and R_A2 are nonce numbers. R_A is used by A to communicate with the KDC. On getting the appropriate reply from the KDC, A starts communicating with B, whence another nonce number R_A2 is used. The first three messages tell B that the message has come from KDC and it has authenticated A.  The second last message authenticates B. The reply from B contains R_B, which is a nonce number generated by B. The last message authenticates A. The last two messages also remove the possibility of replay attack.

However, the problem with this scheme is that if somehow an intruder gets to know the key  K_S ( maybe a year later ), then he can replay the entire thing ( provided he had stored the packets ). One possible solution can be that the ticket contains a time stamp. We could also put a condition that A and B should change the key every month or so. To improve upon the protocol, B should also involve KDC for authentication. We look at one possible improvement here. which is a different protocol.

Otway-Rees Key Exchange Protocol

Here a connection is initiated first. This is followed by key generation. This ensures greater security. B sends the message sent by A to the KDC and the KDC verifies that A, B, R in the two messages are same and R_A and R_B have not been used for some time now. It then sends a common key to both A and B.

In real life all protocols will have time-stamps. This is because we cannot remember all random numbers generated in the past. We ignore packets with higher time stamps than some limit. So we only need to remember nonces for this limit. Looking at these protocols, we can say that designing of protocols is more of an art than science. If there is so much problem in agreeing on a key then should we not use the same key for a long time. The key can be manually typed using a telephone or sent through some other media.

Challenge - Response Protocol

Suppose nodes A and B have a shared key K_AB which was somehow pre-decided between them. Can we have a secure communication between A and B ? We must have some kind of a three way handshake to avoid replay attack So, we need to have some interaction before we start sending the data. A challenges B by sending it a random number R_A and expects an encrypted reply using the pre-decided key K_AB. B then  challenges A by sending it a random number R_B and expects an encrypted reply using the pre-decided key K_AB.

	A	B
1.	A, RA------------->
2.		<--------KAB(RA), RB
3.	KAB(RB)---------->

Unfortunately this scheme is so simple that this will not work.  This protocol works on the assumption that there is a unique connection between A and B. If multiple connections are possible, then this protocol fails. In replay attack, we could repeat the message K_AB(M) if we can somehow convince B that I am A. Here, a node C need not know the shared key to communicate with B. To identify itself as A, C just needs to send K_AB(R_B1) as the response to the challenge-value R_B1 given by B in the first connection. C can remarkably get this value through the second connection by asking B itself to provide the response to its own challenge. Thus, C can verify itself and start communicating freely with B.
Thus, replay of messages becomes possible using the second connection. Any encryption desired, can be obtained by sending the value as R_B2 in the second connection, and obtaining its encrypted value from B itself.

A B 1st Connection:   A, RA------------->         <----------KAB(RA), RB1 2nd Connection:   A, RB1------------>         <--------- KAB(RB1), RB2 1st Connection:   KAB(RB1)--------->

Can we have a simple solution apart from time-stamp ? We could send K_AB(R_A,R_B) in the second message instead of K_AB(R_A) and R_A. It may help if we keep two different keys for different directions. So we share two keys one from A to B and the other from B to A. If we use only one key, then we could use different number spaces ( like even and odd) for the two directions. Then A would not be able to send R_B. So basically we are trying to look at the traffic in two directions as two different traffics. This particular type of attack is called reflection attack.

5 - way handshake

We should tell the sender that the person who initiates the connection should authenticate himself first. So we look at another protocol. Here we are using a 5-way handshake but it is secure. When we combine the messages, then we are changing the order of authentication which is leading to problems. Basically K_AB(R_B) should be sent before K_AB(R_A). If we have a node C in the middle, then C can pose as B and talk to A. So C can do replay attack by sending messages which it had started some time ago.

	A	B
1.	A------------------>
2.		<-----------------RB
3.	KAB(RB)---------->
4.	RA---------------->
5.		<----------KAB(RA)

Fig: 5-way handshake in Challenge-Response Protocol
On initiating a connection B challenges A by sending it a random number R_B and expects an encrypted reply using the pre-decided key K_AB. When A sends back K_AB(R_B), B becomes sure that it is talking to the correct A, since only A knows the shared key. Now A challenges B by sending it a random number R_A, and expects an encrypted reply using the pre-decided key K_AB. When B sends back K_AB(R_A), A becomes sure that it is talking to the  correct B, since only B knows the shared key. However in this case also, if we have a node C in the middle, then C can pose as B and talk to A. So C can do replay attack by sending messages which it had stored some time ago !!