Network Security(Contd...)
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:
- A sends a message encrypted in it's key KA to the KDC. The KDC then sends a common key KS to both A and B encrypted in their respective keys KA and KB. A and B can communicate safely using this key.
- Otherwise A sends a key KS to KDC saying that it wants to talk to B encrypted in the key KA. KDC send a message to B saying that A wants to communicate with you using KS.
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.
RA, RB and RA2 are nonce numbers. RA 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 RA2 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 RB, 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 !!
0 comments:
Post a Comment