 So good morning everybody. Welcome to this session on the second day. There are two theory sessions today. The first one is on security protocols, which discusses basic authentication and key exchange protocols, the basic ideas. There are a variety of ways in which you can do this. Variety of ways in which you can do this wrong also. There are very subtle flaws with the design of security protocols. So we will talk about one or two of them because we may not have that much time for everything. The book has many details on different other flaws and protocols and how they can be rectified and so on and so forth. The second session is on software security, where we will talk about buffer overflow and XSS and web security ideas like SQL injection and cross-site scripting, etc. So with that introduction, and then of course there is a lab in the afternoon and the lab has got two parts. One is a continuation of the wire shock where you are going to see the headers and the contents of every SSL message. So when we talk about authentication protocols and security protocols, the most important one is of course SSL. So whenever you do your internet banking and so on and you type HTTPS that S really stands for SSL or TLS, Transport Layer Security. And that's being implemented by your browser. It's a tunnel that is created between your browser and the server. So the question is, what exactly are the messages that go back and forth? And there are two parts of this. There is the SSL handshake protocol and the record layer protocol. So what are the different messages that go back and forth and can we capture them in wire shock? Can you understand them? What are the headers and those messages, etc. What are the contents? What are the different fields in those messages? That's the lab for today and the other part of the lab for today is on web security where we are going to talk about it in some detail at 2 o'clock. We are going to load one of the vulnerable web applications and you are supposed to hack into those applications starting with SQL injection. So that's the lab for today. So with that basic introduction, let's begin with the first session, Authentication 1. So very, very basic things. Authentication is a process in which a principle proves that he, she is the entity it claims to be. So you know all of this stuff. I'll just go through it quickly. It's occasionally referred to as the prover. So the guy who is trying to prove that he is Bernard, for example, is the prover and the person or the entity to whom the proof is submitted is called the verifier. So A and B, A is trying to authenticate himself or herself or itself to B. A has to prove that it is indeed A and B verifies that proof. Note the principle can be a human being, though it could be a machine, a robot or anything else. As you very well know, authentication is based on what the principle knows. For example, your password or what the principle has. For example, an ID card or a passport or some sort of biometric sample. For example, a fingerprint or iris scan, et cetera, et cetera. So there are different ways in which you can do authentication and we're going to consider it right here on cryptographic authentication. Though nowadays you have multi-factor authentication. You'll use a combination of these things. So you'll see, for example, if you look at a passport, the person's face and the person's photograph and the person's signature, and of course you have to be carrying your passport, et cetera. And these days there are even electronic passports. So there's some cryptography involved with verifying the principle. Authentication types. So once again there are many different types of authentication. Now we are into cryptographic authentication over here. So there is one way authentication. A wants to talk to B. Either A has to prove he's A to B or B has to prove he's B to A or both. So if you do both, then it's referred to as mutual authentication. So there's one way or there is mutual. There are a very rich set of techniques to do authentication. You can do it on the assumption that both parties share a common long-term secret. So you must state the assumption very clearly. So one assumption is both parties share a common long-term secret. Assumption number one. You can do it with the assumption if you use certificate based authentication. Then the other thing is you can use nonces. Everybody knows what is a nonce? Basically a random number that you generate on the fly. So you can use nonces or you can use timestamps. And as I said before, typically entity authentication is accompanied by fill-in-the-blanks. When you talk about almost any authentication protocol, and the major ones these days are SSL TLS at the transport layer, at the network layer IPsec, or you can have one of your wireless protocols, cell phone protocols, wireless LAN protocols, etc. Almost all of them will have two phases. The first phase is authentication, that is entity authentication and key exchange. So we will talk about combining the two things into one. One-way authentication. So A authenticates himself to B or B to A. So think of cases where you might not really need two-way authentication. Think, you don't have to tell me, but you can just think about it. There are situations where you might need only one-way authentication. And then there are of course situations where you need two-way. So let's just start with one-way because that's a simpler thing. Of course, the most basic thing is to send a password across. Now the only problem with sending the password across, so my name is Alka and my password is that XA, exclamation point, two Bs, and so on. The problem with this is two things. Number one is how do you send it? Do you send it in the clear? Then if I tap that line, I can see your password. That's number one. So tapping the line, getting the password as it is communicated. The other thing is getting the password after it's stored. So how do you store that password in the database? Login name and password. Do you store it in the clear like this? Or do you perform some transformation on it before you store it? So both things have to be kept in mind. So would you, for example, store the hash of the password on the server side? If you store the hash of the password, that is open to which sort of attacks? Dictionary attacks. Everybody knows what's a dictionary attack or should I clarify it? Okay, so that's open to dictionary attacks. So be very careful how you handle this whole thing. There are so many different flaws with these protocols that we need to ultimately come up with something that is really secure. And one such example is actually the Kerberos protocol about which we will talk something depending on how much time we have. So the standard view of doing this thing, authentication, is through what's called challenge response protocols. So the verifier challenges the prover with some random number or some nonce and that guy responds with some computation on that random number. So an effective strategy to thwart a replay attack. So if it's sending the same thing all the time, suppose I send my password on the communication line. Okay, you see that's very silly. Let me send the hash of the password. If I send the hash of the password every time I log in and somebody sees the hash of the password, he can use my account, my login name. So suppose in this case, second case, I send the name, alka, and the hash of the password, whatever that is, four, seven, something. Then that's a static quantity that I'm sending every time. So the next time I log in, I send the same thing, the hash of the password. So that doesn't help because you can launch what's called a replay attack. If I see this hash over the communication line, I can just repeat it. So clearly that's not a great idea. What you'd require really is the key thing over here is a challenge response protocol. So the prover submits a challenge, sorry, the verifier submits a challenge, and the prover responds with a response to that challenge, which is typically some function of that challenge. So we will see how that is done. The best thing is to look at these pictures. Everybody can see what's happening now. So let's look at the first example and let's write it down in English. Let's take this in English. Hi, I am Mr. A. First message. That A in quotes means that's my identity. I am Mr. A. What do you think is the second message? By the way, if I don't believe you until you do the following, I give you a nonce. That R stands for random number or nonce. What is this nonce? It is a challenge. I challenge you to do something that only you can do. And what is that something? So that's a slight error over there. It's not E, but it should be the hash function. So think of, just remove that E and put an H there, the cryptographic hash. So what the third message does, A actually computes the hash of his password concatenated with the random number and sends it across. Now here's another example of the use of the cryptographic hash. Yesterday we talked about two uses, computation of the MAC for integrity. So message integrity and entity authentication. And we talked and message authentication, sorry. We also talked about the digital signature where you again use the cryptographic hash. Here is a third example where you use the cryptographic hash in authentication. So this is entity authentication. So that's not E there, but it's H. So I take the cryptographic hash. I concatenate the password and the fresh nonce that has been sent. Notice that this is a fresh nonce. I've just generated it and it's a random number. It's unlikely to repeat. Even if I've done this a million times, it's very unlikely to repeat. If I use a correct random number generator. So this becomes my response. H of PW concatenated with R. There's no reason why you can't do it some other way. First message, I'm Mr. A. Second message, here's my challenge. And third message, guess what? I encrypt that nonce with the password or the function of that password. So typically it's a function, say a hash of the password. I encrypt it and send it back. Now there's no chance of a replay attack. So you see this looks pretty secure. So this is all one-way authentication. Let's look at certificate-based authentication. Just to go a little bit fast, I'll skip too many words and so on and we better look at pictures. That's easier to understand. So what's going on in this picture? The first thing is, A sends to be the certificate chain. So I didn't talk about certificates. I assume most of you know what it is. Then someone say, what is a certificate exactly? So A certificate contains, give me the most important fields inside A certificate. A's credentials, for example, name, employer, maybe address, et cetera, et cetera. So something about A, A's credentials. What else does it contain? The most important thing, digital certificate is a binding between the identity of the person and that person's public key. Okay, so A and A is public key. So that's what's contained in that certificate and I've said certificate chain. I don't know how many of you are familiar with this. We'll talk about it a little bit later so as to not get distracted. But the most important thing is the certificate contains the person's identity, say email address, name, et cetera, and also the person's public key. That's the most important thing, together with things like validity period. This certificate is valid from the 1st of January 2014 to the 31st of December 2016, for example. Okay, it also contains things like which algorithm is used. So the other most important thing is it contains the signature of who. When you say certificate, what does it mean? All of you will get a certificate when you graduate from this five-day course. What is a certificate? What does it certify something? It's signed by somebody, correct? The certification authority. So the certification authority will certify and say that indeed A's public key is this huge string of bits. Okay, and the corresponding private key is held by A, in secrecy. Does the CA know A's private key? Yes or no? Generally no. If you use a certificate only for encryption, there's something called key escrow. Again, I'll explain that if there is time. But only in that case would there be a copy of the private key. But in general, you will never have a copy of the private key with anybody else, especially if you use the private key for signing. Okay, so once again, looking at that picture in the first message, the certificate chain is sent. The second message in the first figure is the nonce again. I challenge you to do what with this. I challenge you if you indeed have the private key, look at the words. If you indeed have the private key corresponding to the public key inside that certificate, then I challenge you to go ahead and perform a private key operation on that R. The words are very important. I'm giving you this random number. You have never seen it before, presumably. And I'm challenging you that if you are the holder of the certificate, if you are behind the certificate, the certificate belongs to you, you are the principal, then you must be having the private key corresponding to the public key in the certificate. Once again, recall, there's a mathematical relationship between the private key and the public key in RSA that E and D are related by E times D is equal to 1 modulo phi of n, phi of n, correct? So that's the same thing we're talking about, the encryption and decryption key. So the private key is with this guy A and the public key is inside a certificate. So I challenge you to take this nonce R and perform a private key operation on it, and then I will verify it. So that's what he does, and he sends that message, the third message. The random number is sort of encrypted, if you will, using the private key of A. And then what happens at the end? So this guy responds, what should I do next? I'm challenging you to do something, so you respond to my challenge. Do I just sit down and do nothing? Perform a public key operation and verify after you perform the public key operation, you indeed recover that original nonce that you yourself generated. It's not something that's replayed in all that business. Everybody sees this? So that's the verification step. Anybody wants me to repeat any of this? Okay. A similar kind of thing in the next example. So this guy sends a certificate chain, and then the challenge now is not R, but he actually takes the public key inside that guy's certificate, and he performs a public key operation on R. And the basic understanding is I challenge you to perform the private key operation and get back R and send it to me. So there are two different ways in which you can do this. Now, what about mutual authentication using a shared secret? Both sides want to verify the other's identity. So first message, hi, I'm A, I want to talk to you. I'm Mr. A, and here's my challenge. I want to make sure I'm talking to the right guy, because I want to talk to B. So he sends this message to B, and then B responds with encrypting this R, A, and sending his own challenge R, B. What is it encrypted by? What do you think is that K? Well, in this case, it would be a long-term secret. Okay, the understanding of it, because the session key business is done a little bit later. So the assumption that I'm making is that both sides, both parties, as I said before, one of the assumptions is both parties have a common long-term shared secret. The other assumption, if you don't want this assumption and you think that's too much of a risk, having these long-term secrets, is having this certificate PKI. So I'm going to do both, actually. So in this case, I'm assuming that both sides have a long-term secret, capital K. So I challenge you to take R, A, and encrypt it with that key K. And by the way, just like I'm responding to your challenge, the second message, just like I'm responding to your challenge, I also challenge you now to encrypt R, B. So that's what he does in the third step. And hopefully, at the end of this, both sides are sure that they're talking to the right person. Any questions about this? Now, this looks very nice and beautiful. And guess what? It's flawed. So that's why this is one of the most difficult topics, security protocols, because you never know where there is a flaw hiding somewhere. So I'm going to show you the flaw. And you tell me what's going on. Who is trying to do what? C is trying to impersonate. Just decide, please, and tell me in one voice what is the final answer. Who is trying to do it? So I think you're right. C is trying to impersonate, fill in the blank. A. C is trying to impersonate A. Just look at the tricks. C is saying, I'm A. Here is my challenge to you. So B says, fine, you're A. Fine, I want to talk to you. So I'm going to take your challenge. I'm going to encrypt it with our long-term secret. That is the secret that B shares with A. And by the way, here is my challenge to you. You should also respond to it. I also want to be convinced that you're the right guy. Now, C starts trembling. I can't continue. Why he can't continue? He doesn't have that long-term secret to respond to this challenge. What is the challenge? RB. That's what he does. Very sharp guy. He says, let me start talking to A. This is called a parallel session attack. As the first session is in progress, I'll start establishing a session to A. So the implicit assumption over here is that C knows A and that A wants to talk to C. So here, C initiates a conversation with A and says, hey, I am B. Sorry, A wants to talk to. The implicit assumption is that A doesn't mind talking to B. So C very happily goes along and says, hey, I am B and here is my challenge. RB. And this guy says, of course, I want to talk to you. So here is my response, EK RB. And here is my challenge to you also, RC. And at that point, C is very, very happy. Why? Because now he can respond to the challenge from B. And full B that he's talking to A. So B thinks he's talking to A. That is the key step, the last two things. C would not have been able to proceed unless he found he could compute this value, EK RB. This is a fresh challenge that has been given to him, this RB. And he has to compute EK RB. But he doesn't know K. That's the common key that is shared between A and B. C pretends to be B and throws this nonce to it. This nonce is RB. And very happily, A is happy to communicate with B. So he encrypts that nonce RB. And that serves as a response to the message, the third message. Everybody sees this attack. Now you challenge your students to improve the protocol to make it secure. So there are multiple ways of doing this. It's a very interesting exercise. Your students will actually love this. So just try and ask them different ways of improving this thing. And one such way is the following. I'm A, here is my challenge to you. RA is my challenge. Okay, fine. I'm responding to the challenge, EK RA. And by the way, this is my challenge to you. What is my challenge? Slight, subtle difference. Again, I choose a random number RB. But now I encrypt it with the long-term key and I send it. Here is my challenge to you, EK RB. Do what with that thing? Perform a decryption operation on that thing using the common key that we shared. If you perform a decryption operation on that, you will get back RB. So I've encrypted my challenge to you. I challenge you to decrypt it and send it back to me. Now you try that other attack, it won't work. But be careful, there might be another attack that works on this. This whole thing is extremely subtle. It's one of the most difficult things in this course, these protocols. Okay, we've talked about long-term secrets. As I said, the second paradigm is where both sides might have certificates. So certificate-based mutual authentication. So I've not shown the certificates being passed, but it's assumed that you passed them. Again, I am A and here's my challenge to you. RA, what should you do with the challenge? I expect you to do the following. I expect you to compose a message with your identity first. Sorry, with my identity first, that is A, then the nonce that I just gave you, and then you put your own challenge because this is mutual authentication, you should do it also. You also challenge me. And what is the rest of that thing? You see that the box bracket and then a B at the bottom. Is it encrypted? It's a signature. So that notation in protocol theory stands for a signature. So compose this message. The first part of the message is the identity of A. So B has to do this, the identity of A, then the nonce that A gave it. And now, of course, you have your own right to challenge me. So you put your nonce over there. Take this entire message, send the message to me, but in addition to sending the message, also sign the message with your private key. If you can sign it correctly and I can verify your signature, then I'm convinced that you're the right guy. So please do that and send it across. A tells B. So B does that. He puts A, the identity of A, the name or whatever, and then the nonce RA that he's received and his own nonce. This entire message, he signs it. So this means send this entire triplet and also send the signature along with it. And then what does A do when he receives it? Verify the signature, right? Anybody signs and then you have to verify, just like encrypt and decrypt. So the next thing that happens is that A verifies the signature. If he verifies correctly, then if it verifies correctly, then he's sure that it is B at the other end. Notice, is there any chance of a replay attack? Why or why not? The nonces are the key things over here. This is a fresh nonce. I've never seen it before. The space of these nonces can be very large, say 128 bits. So there are two raised to 128 possibilities. The chance of a nonce being repeated is almost zero. I can live 10 times on the earth and the nonce will not repeat. It's as improbable that that nonce will repeat. Not even in a thousand years, okay? So he verifies the signature, that is A verifies the signature and then what does he do? He also has to respond to A's challenge, to B's challenge. So he does. He takes B, the identity of the recipient, that is B and the challenge given by the recipient, RB. He takes it, puts it together and signs it with his own private key. So you see the difference between now. So we are talking now about mutual authentication, two paradigms where both sides share a long-term secret and the second paradigm where both sides have certificates. So just look at the picture. If there are any questions, please ask. Is there an assumption that A should prove certificate of B? Very good. Is there an assumption that A should possess the certificate of B? The answer is yes. So I'm assuming that they send it in those messages. So for example, in the first message, A should send a certificate and the second message, B should send a certificate or they already have each other's certificate. There is a table maintained at both the end for RA and RB. For what? For? Table maintained. RA and RB. Very good question. It should not be repeated again. Is there a table maintained for RA? Because the security of this protocol depends on not repeating the nonce. If you repeat the nonce by mistake, then of course you are open to a replay attack. So her question is... If we can... If we can... Yes. It can be replayed. If you don't maintain the same... No, it can be replayed if this guy's challenge is RB. If it's the same challenge is given again. So that is why it should be random. If it is random and suppose something like 128 bits, then the total space of those nonces is 2 raised to 128. So the probability that the same value repeats again is infinitesimally low. Sir, why do we put B's identity in third message? Okay, good question. Why do we put those identities over there? Give this question to your students and tell them to hack that protocol. Don't put those identities and see whether it can be hacked. So this is a little exercise. So it's a very important statement. You will see in many protocols that there will be identities of the recipient, for example, put inside that thing and it's signed. Please do this exercise. We won't have time to do it over here, but try it out. Don't put those identities and see whether the protocol becomes insecure. There are all these very, very subtle things about security protocols. And this can only come through practice. You see, if you just try it out, try it out, try it out again, and let your students, the first time you teach all this stuff, you might make some mistakes on the board, challenge your students. The students are sometimes very, very bright. They will come up with all the most weird kinds of things. But never mind. Let them come up with it. Let them come up with flaws and improve protocols. Yes. If mutual authentication with more than two users, same challenge is going to be used for multiple persons. Are you talking about three people communicating? Yeah. A group communication. Yeah. Yeah. So this cannot be used over there. In that case, typically what is used is some kind of variation of Diffie-Hellman to come up with a common key for three parties. Okay. So this is all basically a description of the figure. So I'll just skip it. Now the next variation is mutual authentication plus key exchange. So we're going to add key exchange, as it's usually done, using a shared secret. So once again, let's see what's going on. The shared secret is obviously capital K. I'm A. Here is my challenge to you. And my response is, as before, E-K-R-A. And then previously we just had E-K-R-B. And now there's some new thing over there. What do you think that new thing is? So there's an SB and an SA. Can you clarify what that is? They are both pieces or components of the session key. Yeah. It is good security practice. If two guys want to communicate, it's good security practice that both sides have the opportunity to contribute to the session key. Instead of just one guy unilaterally deciding that this is the session key. Both are contributing towards creating... Yes, yes. So the question, the comment was, in Diffie-Hellman both parties contribute to the shared key, A and B, G raise to A, G raise to B, etc. Over here also that is done. There will be certain times where only one party contributes. In the case of SSL, as we will soon see, it's only the client that contributes to the master secret or the pre-master secret. But then both sides contribute towards the master secret. So there's a pre-master secret and a master secret. There's a reason for that. We'll come to that very soon. So it's very similar to what one of the previous slides, except here that I'm injecting also this SA and SB, which are random numbers and SA concatenated with SB gives you the final session key. So once again mutual authentication plus key exchange before we had just with a long-term secret, now with certificates. Again, a variation of one of the previous slides. To be on the safe side, I'm putting both guys identity. I am A and I want to talk to you, Mr. B. So I must encrypt the session key. My contribution to the session key. Encrypted what? So my contribution, B's contribution, is going to be encrypted with A's public key. So that's why I have E, A.PU, SB. SB is B's contribution to the session key. Why use nonces? We could also use timestamps. There is a synchronization problem, but assume we can solve the synchronization problem. What is the advantage of using timestamps? Maybe I can use fewer messages. Previously we had three messages, here we have only two. So hi, I'm A. I'd like to talk to B. Here is my current timestamp, which doesn't repeat, of course. So TA. Here's my contribution to the session key SA. I don't want anyone to see SA, so I'm encrypting this whole thing using your public key, which presumably I have already. So the assumption over here is that A already has B's certificate. How come A won't be the public key, because you're not going to communicate? So that's the assumption I'm making. If that assumption doesn't hold, then unfortunately you'll have three messages. I'm trying to be stingy with the number of messages. Instead of three, have just two and make it simple. So in order to do this, the assumption that is made is that A and B are good friends, and they know each other's certificates from before. That is only the same case again. Yes. In that case, A's certificate and B's certificate in this picture. So that's my challenge to you. What is exactly my challenge? How do I trust you? How do these guys trust each other? How do I know if I'm B and I receive this first message, how do I really know you're A? Not only that, but I mean that TA, that timestamp, is it unique? Presumably. It varies the function of time every single microsecond or maybe nanosecond, you increment it. So it's a fresh thing each time. You do this sort of thing. Fresh thing. And yeah, SA is also fresh. So I encrypt the entire thing using B's public key and then I sign it. So now when I sign it, you can verify my signature. So there are two aspects of it. The freshness of that TA and the signature. So B can verify the public key of A using the A certificate. Yes, it's assumed that B already has, or you can just send A certificate over here. But the question of course is how did A know B's public key? Because you see the very first message, it's presumed that A knows B's public key. How come? Well, I'm just making the assumption that they have been communicating with each other in the past. So if this is a first time communication, then of course A cannot proceed with this unless A gets B certificate. The authentication may be required here, is it? Third party application. Third party authentication. There may be a key distribution server with whom A and B has been already registered. And key distribution server would have certified both A and B. That way you can assume. So we'll come to that. That's another paradigm where you have a key distribution center. So far I'm not assuming that. I'm talking about the whole idea of certificates came. If you ask yourself this thing, what is the need for a certificate? If you know somebody's ID, whatever that ID be, you would like to find the corresponding public key. So my first thought when I encountered all this about 15 years ago was why don't you go to one website which posts everybody's name and everybody's corresponding public key? What is this whole business of PKI and sending certificates around the place? The whole business of sending certificates is to make this whole thing distributed. I don't want a centralized guy, because that centralized guy gets killed, dies, or if he's congested, then I will be delayed. So certificates was a solution to that problem, making it completely distributed. Ironically enough, this opened the door to another complication. You know what that other complication is? One of the key problems with PKI. Certificate revocation. Just because it says your certificate is valid from 1st of January 2014 to 31st December 2016, doesn't actually mean it is currently valid. What if your private key were compromised? I'm asking a very simple question. I'm not a very careful person, so my private key was lying around in some disc or something, somebody hacked into it, and now it's been compromised. Then what happened? Then that person can sign on my behalf, correct? He can forge everything, every single document. He can forge my signature on any document. Now what happens? Just think about these little problems. I didn't want to bring it up because it will take time. It's all in the book, actually. Revocation ideas. So I've got a certificate where the private key corresponding to the public key in that certificate is used for signing. That private key has been compromised. It's been hacked and obtained by somebody else. So now on, that guy could sign documents on my behalf claiming he's me. Now you are the verifier. You're verifying my signature. If that guy sends my... The certificate is floating around everywhere. If that guy signs an arbitrary document with my private key and sends that certificate, you will think that I signed that document. You will look at the certificate, say the validity period is this to this, fine. It's only May right now, so it's valid. But actually, should it be valid? That certificate should not have any validity at this point because it should be revoked. How do you take care of revocation? Now you have a centralized solution. You have to go to a centralized server and say, hey, look, I've just got the certificate, but I'm not sure it's valid anymore. Can you please check it's valid? So if you are going to go to a revocation server, then why have certificates in the first place? I could just go to them anyway, right? So there is a little bit of all this stuff. So it's not as simple a problem as you might think. PKI has its disadvantages. We can try to get rid of them, but it's not that easy. So I'll talk about EKE after we've talked about Diffie-Hellman and so on and the discrete law problem. So in terms of authentication, we've talked about two things now where they share a common secret and where there is a certificate-based authentication. So one thing I want to clarify again, just receiving somebody's certificate doesn't convince me at all that it's A. Suppose somebody's at that end sends me a certificate and says, I'm A. Do you think I should believe him? Please understand this. Absolutely not. Just having somebody's certificate and sending it to me doesn't mean I'm going to believe that you're that person because that person is sending the certificate all over the internet and anybody can grab Gmail certificate or Google certificate or Microsoft certificate or Bill Gates certificate or anybody's certificate. That doesn't mean that you're Bill Gates just because you gave me a certificate. You need to do something and that something is typically what? To convince me that you are Bill Gates, it's not enough for you to just give me Bill Gates certificate. You have to do something else. What is that something else? You have to perform a private key operation with a private key corresponding to the public key inside that certificate. Then and only then I will believe you. That's exactly what is done in those previous protocols, certificate-based authentication. Now we come up with the third paradigm. The problem with secret key as we know is key management. If I talk about these long-term secrets, then I've got to have for each one, I'm communicating with different long-term secret with each person and so on. That is obviously not very practical. The certificate problem has its other issues like revocation but also as we know, public key cryptography is somewhat slower. Can we think of an alternative approach? And that alternative approach is precisely that, the use of a KDC or key distribution center. So what is this thing exactly? So third approach is to employ a trusted third party which functions as a key distribution center. So each user registers, how many of you are familiar with Kerberos? Okay, a fair number. So the protocol behind Kerberos is something called Needham Schroder. So another very interesting protocol with a couple of flaws. The initial protocol had many flaws. So each user in this KDC-based system registers with a KDC and chooses a password, a long-term secret which is a function of the password is exclusively shared by that user and the KDC. So visualize you've got many different users now and many different servers even. And you have a KDC with which you share a long-term secret like a password. So that secret basically is a function of the password, not usually the password, but a function of the password. The main function of the KDC or key distribution center is to securely communicate a fresh common session key to the two parties that wish to communicate with each other. So if I tell the KDC, I want to talk to A, so here's the basic idea. I share a long-term secret with the KDC. B shares a long-term secret with the KDC, et cetera, et cetera. Now I want to talk to B. So I go to the KDC and say I want to talk to B. And then what does the KDC do? It sends a short-term session key to both me, A, and also to B. So from now on, I can communicate with B in a secure fashion for the duration of that session. If I want another session tomorrow, then again I go to him and say I want to talk to B, now give me another session key. This session key shouldn't persist for too long. You should keep refreshing them every, say, 10 minutes or so. So here's the picture of this. So A goes to B and says I wish to communicate, goes to the KDC, and says I'm A. I wish to communicate with B. So what's the response? He says okay, here's the session key which you should use to talk to B for the duration of the session. And so I don't want anybody else to see it, so I encrypted using what? The long-term secret that A shares with the KDC, the password. A function of the password, that thing. A at the bottom, and the key, the long-term key is a function of the password. And also the KDC gives B something. That something is, again, the session key encrypted with the long-term secret that B shares with the KDC. So are there any problems with this approach that one can think of? There are many, many problems. Let us look at one solution to some of those problems, and let's see if this has its own problems. So the first thing is, if you look at that picture, one of the things is synchronization. I don't know when these messages are going to arrive. They're not very well synchronized. The message from the KDC could arrive to B before it arrives to A and so on and so forth. There has to be some better protocol. It's too simple, a protocol for KDC-based authentication. So here is a good attempt. First message, I am A. I want to talk to B. So guess what the case KDC does? I'm going to encrypt this session key to U and also in the same message, you take care of giving it to B. I'm not going to give it to B. You take care of giving it to B. So I'm giving you this message which you should give to B. That message, the identity of A, just think about it logically. The identity of A and this session key encrypted with the long-term secret that B shares with the KDC. Look at the second message. It makes sense, right? What is my duty to you, the KDC says? My duty is to give you the session key. Give it to you securely. That's why I'm encrypting it with the long-term secret that I shared to you. But my other duty is also to make sure that B gets that session key. So I'm creating another part of that message which contains that session key and which is encrypted with the long-term secret that the KDC shares with B. So what does A do now? He sends that so-called ticket, that's known as a ticket, that EBA, KAB. So he sends the ticket across to B and what is the rest of that protocol? Sending a nonce. I challenge you, if you are B, then you better be able to take that R1, I mean take that EAB R1, decrypt it to get R1, decrement that R1 by 1 and add your own nonce to challenge me because you also want to challenge me. Add your own nonce R2 to challenge me and then encrypt the entire thing with the session key. So that is message 4 and then message 5 is I take the nonce that you have given me and I decrement it and I encrypt it with the session key. Do you see this whole thing? So you can see how complicated these protocols can get. Just look at this thing and actually as it turns out there are numerous flaws. It looks very nice but there are flaws. First and foremost, any clarifications about what is happening? Okay, very good question. Is there any specific reason for decrementing that R1? Why do you not just want to encrypt R1, R2 and send it? Why R1 minus 1, R2 and then encrypt and then send it? Anybody can guess? It's a very subtle answer. Time stamp, I think. What time stamp? I'm not using any time stamps in this protocol. This is like a sequence of synchronization. I think this is a key session. Session has started from KDC. No, but I mean do you see anything immediately wrong with just not decrementing the nonce just sending it? Because it's a new message, right? R1 comma R2. Suppose I didn't decrement it. EAB R1 comma R2. It's a new message. Do you really see this being a problem? The problem is think of your different modes of using. So this is using secret key cryptography. Yes. Okay, now think of the different modes. If for example, see in security you always have to be paranoid. If you use ECB mode, what is ECB? Electronic code book. Electronic code book mode, the most basic mode. If you use ECB mode, then what might happen is that that EAB R1 in the previous message. Just look at the previous message. You see an EAB R1. That same thing, the encrypted version of R1 could be used in the second message. If you're using without initialization vector and so on, you can use that same field in the next message from message three to message four. These are all very, very, very subtle things. So hackers could observe that message number three and see this particular field, this particular 128 bits corresponds to EAB R1. And the first 128 bits of the next message should be the same thing. Therefore, I don't have to do any work. I just take those 128 bits from message three and inject them into message four and I have responded to the challenge. So be very careful. So just to take care of this, assuming that you're not using ECB mode, that you're not using CBC mode with an initialization vector and so on. If you don't do all those things, then of course there could be a problem. Assuming that he knows long secret key between KDC and B. We are assuming that B? That B shares long secret key with KDC, that is B, encrypted with B. Yes. The first packet in the third message. Unless it until B decrypted, he will not be able to know the value of R1. He will not be able to, yes. Yeah. Exactly. So what we're doing in step number three is, so what you're saying is you're assuming that B knows that key. KAB is encrypted with a long secret key shared with KDC. Yes. Shared between B and KDC. Right. Unless and until first packet is decrypted. Exactly. Second packet will not be decrypted. Exactly. So it is assumed that B shares a long term secret with the KDC. So the environment that we're talking about over here is something like a campus where all of us have a relationship with the KDC. And so each of us has a long term secret with the KDC. So B will have a long term secret with the KDC. If I just mentioned B's name to KDC, then KDC will look up a table and see if this is B, then this is a long term secret I shared with B. And that's how he encrypts that message. Now believe it or not, there are many hacks into this thing. What is going on over here? X is trying to impersonate B. So X is watching out, looking at what A is doing. Whenever A is trying to talk to B, A says I'll stand in the way and convince A that I would like to make sure that I impersonate B. So I'll stand in the way and convince A that he's talking to B when instead he's talking to me. I will prove to him that I'm actually B, even though I'm X. So look at how he goes about doing this. He comes in the middle over there, the standard man in the middle attack. So we talked about replay, now this is man in the middle. He stands in the way there. The first message as we've seen before, hi I'm A and I want to talk to B. This message has to be sent to the KDC. This guy stands in the way and says, this is the message from A. He's A and he wants to talk to X. X is another guy on the same campus. So he shares a long-term secret with the KDC. That is the assumption. So KDC says this, sees this, says okay, fine. Let me go ahead and generate the ticket, EX, A, K, X. So he thinks that A wants to talk to X. So he encrypts that ticket with the long-term secret that X shares with the KDC and takes that together with the session key and encrypts it with A's long-term secret. Sends it to A. So A just pulls out that ticket, EX, A, K, A, X. He doesn't know that this is encrypted with X's long-term secret and so on. He thinks it is B because he doesn't know anything about B's long-term secret. So he just sends it across and once again X stands in the middle over there in front of B and intercepts the message. Now what does X do? X is very happy at this point. So he sees that first message is the ticket and he's able to decrypt it and what? X stands in the way. He's able to decrypt the ticket and extract the session key very happily. So he extracts the session key and then he's able to respond to the challenge because the challenge from A is EX, R1. I challenge you to decrypt that value and send it back after decrementing it. So the book tries to improve this, fix it up but then there's another flaw and yet another flaw. So just look at it for another minute and then we'll continue. KDC has to authenticate A. Before sending the session key. First message could we get signed by A? Yes. So there are various fixes to this. One thing is A can put a nonce over there and so on and so forth. So yes, authenticate A in the beginning. Make sure there's something special that only A could do. The only question is there are many solutions. Which one is the most economical in the number of operations that you have to perform and in the number of messages that have to be exchanged? So the whole treatment of this thing is in the book. I will just show you the final, final solution over here which uses some more nonces and so on. So this is one solution but there are other solutions. So the whole idea is to try to generate a couple of nonces so that there is freshness of these messages. So in the previous version there was only one nonce but over here there are many more nonces. R3, R4, etc. The whole purpose of putting the nonces is to guarantee freshness. I don't want to write. It should be like B2. Oh sorry, sorry. The message 6 is from B to A. In one, two, there is nonce, R4, R1. Message number 2. So what B is doing is he is saying I challenge you to be able to decrypt this thing. So I have chosen a nonce R4. I challenge you to decrypt it and include it in the ticket. Is it R4? Yes. But in message number 6 it is something R1 where that R1 has come. In message number 6. He is doing R1 minus 1. Yeah, so that should be actually the message number 5 it should be R1. EAB instead of R2 it should be R1. When type setting sometimes there are some of these things and I didn't notice that it was type set wrongly. In message number 5 it is R1. Yes. That is like the previous thing. Those steps are like the previous thing. I have just added the R3 and the R4. R3 is in message 3. So the exercise is to try to remove some of those nonces and see if there is a problem. Try to remove some of those identities and see if there is a problem. Do this in class with your students and challenge them and see if anybody can come with a flaw. Suppose I didn't put one of those identities somewhere, could there be a problem? If I remove one of those say R3, didn't have R3 at all or didn't have R4 at all, will there be a problem? Can R4 or to guarantee the freshness of those messages? So notice that this solution doesn't use timestamps. Just nonces. The next protocol which is called Kerberos was inspired by Needham Shroda. This is the Needham Shroda protocol, the final version. Sorry. Even there will be a man in middle attack at the first step itself, right? Could there really be? Yeah. Suppose I stood there and put X over there. Yes. So then, no, well, man in the middle, if I put X, then it won't go to B, right? B will see X over there and say this is phony. But X is going to send its non-sto A. No, here I'm communicating directly with B in the first message. Okay. So I'm saying I'm A and I want to communicate with you, Mr. B. Please. Are you talking about the first message or which one? Second message. Yes. From B to A is EB of R4. Yeah, yeah. So it is to be decrypted by A? No, no. EB R4, basically that's to be decrypted by the only guy who can decrypt it other than B. Yeah. Who is the KDC? So that is being copied. So basically what he's saying, just look at the semantics of this message. What B is saying is, I'm giving you a nonce R4. You've never seen that before. I'm encrypting it to you. If you really are the KDC, ultimately the KDC has to receive this. If you really are the KDC, you and only you can decrypt it and get out R4. If you can do it, take that R4 and put it inside the ticket. That's it. That is just, it is copied. Sir, I said here, excuse me, sir. Yeah, yeah. I said here, if X is impersonate B. Yes. It is going to send its non-sto A. Right? Non-sto A is not going to encrypt it. It's simply forwarded to KDC. So what you can do is, KDC is going to return back the session key for X and A. Then. Okay. So A and X, correct? First message. Yes. And X receives this thing. Then what does X do? He encrypts it with, encrypts some nonce with EX, correct? Yes. Am I right? Yes. So now what will happen is KDC will get A comma X. Some nonce of encrypted nonce of X. Right. And it returns back the X identity. I am pretty sure it won't work. Can we discuss it a little offline? Just after this lecture is over. Just over the tea break we can just discuss. Okay. You tell me what exactly is your attack and we'll see whether it can still work. Yeah, sure. Okay. So let's just proceed to attack Kerberos and SSL. So if you've got any other attacks on this, just let me know. So I'll get in touch with this gentleman to look at his attack. So they said Kerberos is another very, very widely used protocol. It's implemented in Microsoft operating systems, et cetera. And it was inspired by Needham Schroeder. So the goal over here is you've got multiple, not just users in the system, but you've also got multiple servers. So given a network with multiple users and multiple servers in an organization such as university campus, the next thing is, so these are all the wish lists that I have. A user once logged in may then wish to access different resources such as an email server or a file server in the course of that login session. I don't want this headache of going to each server and authenticating myself to that server and so on and so forth with a separate password. That's what I don't want to do. So one possibility is for the user to have multiple passwords on each of these servers. However, having humans remember and update multiple passwords is not very practical. So that's the first thing. Just a single sign-on, just one password. A user could use the same password for all servers. Hey, but wait a second. Distributing and maintaining a password file across multiple servers is a security risk. Then the password should not be transmitted in the clear. It should not be able to launch dictionary attacks using the eavesdropped upon messages containing a function of the password. The password itself should not be stored on the authentication server. Rather, it should be cryptographically transformed. So it should not be stored in the clear. It should be cryptographically transformed before being stored. Further, it should not be possible to launch dictionary attacks by obtaining a file. If the system administrator gave you a file containing those hashes, you should not be able to launch a dictionary attack on them. So it should not be possible to launch a dictionary attack by obtaining a file containing cryptographically transformed versions of the password. Some more things on this wish list. A user enters her password only once during login. Thereafter, she should not have to re-enter the password to access other servers for the duration of the session. I just do it once on just one machine. This feature is called single sign-on. Another thing, the password should reside in a machine for only a few milliseconds after being entered by the user. So once the user enters the password, it should be there for just a few milliseconds and then should be destroyed. Thereafter, all vestiges of the password should be destroyed. An image of the password should not linger on in either volatile or non-volatile memory of that client machine. So with all these things on my wish list, can we design a nice system over here? The solution was Kerberos, and again, as you know, since protocol design is very hard, this has gone through multiple revisions with multiple flaws in each version. So this is a widely used protocol supported on various operating systems including some of the Microsoft OSes. Now the KDC that you saw in the Needham-Schroder protocol still exists over here, but it is logically split into two entities, the so-called authentication server and the ticket granting server. The ticket as mentioned before is the mechanism used to safely distribute session keys. Once again, each human user A of the system shares a secret KA with the authentication server. The secret is essentially the hash of the user's password. And likewise, each server B, so we're talking about humans first, users, A is a user and B is a server. So each server B shares a secret KB with the ticket granting server. So there are two servers, the authentication server and the ticket granting server. Unlike the Needham-Schroder protocol, Kerberos makes extensive use of timestamps. So I won't go through all of the messages and the content of them, just the basic idea. So the AS is involved in authenticating a user when she attempts to log on to the system. The AS then issues something called a ticket granting ticket to the user. So you have logged in to me to this authentication server. I will give you a ticket granting ticket, just keep it carefully and use it for the duration of the session. Whenever you want to go and get the services of any other server, you will need to use it. So this is the ticket granting ticket, which you get from the authentication server. Now, for each different server that needs to be accessed, the client approaches the TGS. So first you approach the AS to get the TGT. Now you approach the TGS for each subsequent service that you require to access. So for each different server that needs to be accessed, the client approaches the TGS with the TGT. The TGS first authenticates the user and then provides the user with a service granting ticket to be handed over to the server whose service is required, which is then going to be followed by mutual authentication between the client and that particular requested server. So believe it or not, just six elegant messages, I'm not showing you the contents, the contents are in the book. These are the messages. I want a ticket granting ticket, the first message, and I get a ticket granting ticket. Then each time, so this is a one short thing, when you log in, you get a ticket granting ticket. Then subsequently each time you need to access a server, you have to go to the TGS, not the AS anymore, the ticket granting server, and produce the TGT to that TGS. And on the strength of that TGT, you will be granted a service granting ticket. So you will produce the TGT in message number three and request a service granting ticket. So you produce the ticket granting ticket and you request a service granting ticket in message three, and that's what you receive in message four. And then in message five and six, you will authenticate, you'll be given session keys and so on, and you'll authenticate yourself, mutual authentication between the client and the server. So the details of those messages are in the book. So I would like to spend some time on looking at one of those hacks. I don't know whether to do it right now or whether to do it after the break, because we would like to at least take one thing where some of us can come over here, draw the hack, can see it. But so what I'll do is I'll just start SSL and then we'll take a break. We'll complete SSL and look at the hack and then go on to software security. Are there any quick questions? Somebody had a question. Is there any specific application that you have to go to? Is there any specific application? Is there any specific? Yeah. So the servers could be multiple things. So the question was, is there any specific application relevant to this? And those servers could be anything. There could be FTP servers. There could be mail servers, et cetera, et cetera. Any kind of server, printer server, anything which requires you to authenticate yourself too. The point is, I don't want to authenticate myself repeatedly, this headache, of again and again and again authenticating myself to somebody. What he's done is the system automatically submits that ticket granting ticket to the ticket granting server and gets a service granting ticket, which he then submits to the server itself. So that's the general idea. Just give me this TGT at the start and then I will use it every subsequent request to a server. Any specific application? In a web application? Yes. Whenever, if you're using Kerberos in your organization, whenever you request the services of most of these servers, you would use something like this. It does away with PKI, though there is another version of Kerberos which uses public key, the public key infrastructure. Can you name the application that is used in Windows Server 2008? If they have single sign-on, which I believe they do, then almost all likelihood it would be Kerberos or some version of it. The name of the application itself is Kerberos. Well, the system is Kerberos, that is to say the security infrastructure is based on Kerberos. The single sign-on system. When you say single sign-on, this is what you mean.