 Are we ready for this? Let's at least get started on this. This is the most important protocol. Let's get started on it and we'll complete it after the break. So the main protocols that are used today would be SSLTLS, IPSEC. If you are looking at banking infrastructure, core banking, where you have to connect multiple branches of a bank, think of the state bank of India, that has got what? How many branches? Anybody? More than. More than? 84. 84. 8,000. My guess is it's around 20,000. So 20,000 branches all have to be connected to the core, which is somewhere in, let's say, Mumbai with a backup somewhere else, and so on. And any transaction you do, say debiting from this account or transferring from this to that, every single transaction, whichever branch across the country you are, it will hit the core server in Navi Mumbai. Now you have to make this thing very, very secure. So the question then is, what should I do in such a situation? Do I use something called a VPN, virtual private network? The answer is yes. You will use a virtual private network. The next question is, what security protocol is in use in a VPN? And the answer to that is, is it SSL? It turns out to be IPSEC. So the most common protocols are SSL, IPSEC, Kerberos, and all the wireless protocols either for wireless LANs or for cell phones. So I'm not covering all of that because we don't have time for everything, nor am I covering IPSEC. So IPSEC came before SSL. It's a very complicated protocol, unnecessarily complicated. And as you will see, SSL is much neater, much cleaner, much simpler. So the goal is to try to understand it and then go to the lab and figure out what is inside all those messages. What are the messages and what's inside those messages? So SSL is emerged as the principal means of securing communications between an internet client such as a browser and a server. It was developed by a browser called Netscape, browser manufacturer called Netscape, way back in 1994. It was standardized by IETF. What is that? Internet Engineering Task Force in 1999 and then called TLS, Transport Layer Security. Today, SSL and TLS are used interchangeably. Where does this thing lie in the seven-layer model or four-layer model or whatever you have? SSL is sandwiched between TCP. It only runs over TCP and an application-layer protocol. Protocols such as HTTP, FTP, SMTP, IMAP, and POP can be run over SSL. Application protocols that are secured by SSL are usually suffixed by an S. For example, HTTPS. So a picture of this thing. It's actually multiple protocols in one. So there is two layers or two sub-layers. On top, you have the handshake, the main protocol, and some smaller things like the alert protocol and change life of spec protocol. And then just below it, you have the SSL record-layer protocol. So there are two parts. As I said before, almost all modern security protocols have two phases. The first phase is what? Entity Authentication and Key Exchange. And the second phase is your regular exchange of messages which are integrity protected and optionally encrypted. So that's what that second sub-layer does. For every single message thereafter, you integrity protected and possibly encrypted. So that's what we just said. The handshake protocol and the record-layer protocol. What does SSL provide? Server Authentication, this is mandatory. Client Authentication, optional. Why? You don't want to authenticate the client. Just look at this list and tell me whether it makes sense. The nice thing about SSL is it's a very practical protocol. There are reasons why certain things are optional and so on. Server Authentication mandatory. How could that be done? And why you think client authentication is optional? Sir, we can't think about it. But do you think, for example, so suppose I was to say, take internet banking. The banking is required, but if you go with some other, let's say it is not extra. Okay, so if it is required in internet banking, then how do you do authentication? I mean, how do you do client authentication? Can you clarify? Can anyone clarify this? No, sir. Use a name or password. Right. Use a name and log a name and password. Yeah. Is that done in the handshake? No. So that's the key thing to realize. In many applications such as internet banking, you do require both client authentication and server authentication. So you might ask yourself, why doesn't the handshake also provide? I mean, if you require it for so many applications, why doesn't the handshake also provide client authentication? What is the answer to that question? See, the answer is a very practical thing. If you wanted client authentication in the handshake, then the client would be expected to have a digital certificate. But how many of us have digital certificates over here? Or how many have, say, people on the street? How many of them have digital certificates? Almost nobody. Now, does it mean you cannot use SSL? So let us come up with a way in which, even though you don't have a digital certificate, you can still use SSL, provided that the server has a digital certificate. Now, the server is a big guy, like a bank and so on. So obviously, the server must have a digital certificate and must support PKI. But I'm not expecting everybody else to have a certificate. So we must have a protocol that allows this possibility, that only the server has a certificate, but the client does not. So the next question is, but surely in internet banking, you do need to have the client being authenticated. How do you do that? Obviously, with the password. So that's exactly what SSL does. The SSL handshake layer will create a secure tunnel. And across that tunnel, in the SSL record layer protocol, you will actually send your password through that tunnel. So look at the idea. This becomes very practical and that is the reason why everybody uses it and can use it. Because you don't really require clients to have certificates. You just require the server to have a certificate. So client authentication is optional. Message authentication is mandatory. So message authentication and integrity checking, almost always you require that. You want to make sure that every message is not tampered with in transit and that it originates from the source it claims to originate from. And that is obtained using or that is affected using a Mac. And then message confidentiality. So you can definitely think of, as I said yesterday, you can think of applications where I want to know for sure that when I go to this website, it is really that website that is saying the T-shirt cost 500 and not 5,000, but I don't really care whether that message is encrypted to me or not. So that is why in general, message confidentiality is optional and also to provide confidentiality, you require a compute power. So if you don't require it, we can just shut it off. And then non-repudiation, for exactly the same reason as before, you have server non-repudiation, but you don't have client non-repudiation because to have non-repudiation, you would have to sign. And to have a sign, to sign, you would need a private key and a corresponding public key inside a certificate, which I don't expect anyone to have in general. So the main steps are agreement and a common cipher suite to be used in the new session, receipt and validation of the server certificate by the client, communication of a pre-master secret and computation of the derived secrets. What are these secrets? Derived secrets for what? There are actually six of them. What do you need all these so many secrets for? At least give me two secrets. So look at the idea. You have a pre-master secret and then from that we're going to get a master secret and from the master secret we're going to get these six derived secrets. My question is, what is the point in having so many secrets? For what? What are you going to do with all these secrets? What do you use these secrets for? The Mac, right? The Mac is nothing else, but the other term for Mac, better term perhaps is a keyed hash for integrity protection, integrity protecting the messages. So you have to compute the keyed hash, the Mac, so you need secrets for that. You need at least one secret for that. What they do is from A to B, you have one secret for all messages starting here and ending there and another secret for all messages from there to there. So two keyed hashes sort of. I mean two different keys for the keyed hash from this direction and the keyed hash in that direction. Then again encryption. If I'm encrypting things, if I'm sending from here to there, I use one secret. If that guy is sending to me, I use two secrets and there are two more initialization vectors also. So there are six different secrets that are finally derived from the master secret. And the master secret comes from the pre-master secret. This is a really beautiful protocol. Everything is so beautifully and well thought out. Integrity verification of handshake messages and server authentication. So that's one of the things. So many people say, how did you do server authentication if I asked people or if I see some books? They say server authentication was done when you receive the server's certificate. One of the very worst things you can ever say. Is that the reason? I mean, is that the thing? Is that reality? I just get somebody's certificate. As I said, you have Bill Gates certificate. Am I supposed to believe you have Bill Gates? Obviously not. So there must be something more that is going on. I would like you to tell me how is authentication actually done? I'm talking about entity authentication. So these are the messages which you will capture in your lab today using Bioshock. First message, client hello. Then server hello. Then server certificate. Note there is no client certificate. Then client key exchange. And then change cipher spec message. And the finished message. And change cipher spec and finished. So let's see what each of those things has. Information exchange in the hello messages. What do you think should be exchanged? The algorithms that are going to be used. So basically there's a process of negotiations. I can support this and you can support that. Which secret key algorithm can you support? Which key exchange method can you support? Which hash algorithm can you support? All of that has to be stated in your client hello message. And likewise in the server hello message. And then we'll agree on a common cipher suite. So the algorithm to be used in computing the MAC for the message integrity. So either MD5, Shavan or whatever else. Whether or not message confidentiality is required. And if so, which algorithm? AES, AC4, etc. The key exchange method used for communicating the pre-master secret. So there are several key exchange methods. As someone mentioned, Diffie-Hellman is one, but you can also use RSA, etc. And then, very importantly you tell me what this is going to be used for. 232-bit nonsense, and you will see those nonsense in your wireshark screen. RA chosen by the client and RB chosen by the server, which is done in this step. Sorry? I believe it's byte. So you just check that up on your Wireshark screen. Certificate, server certificate. The server communicates its certificate to the client. On receipt of the certificate, what does the client do? It checks the owner's name URL and the validity period. It also verifies the signature of the CA on the certificate. So what is the certificate? HDFC Bank is sending me the certificate. I'm the user. What does that certificate say? I am HDFC Bank, or this is HDFC Bank, and its public key is this, signed by the CA. So I have to verify the signature. Do I have? What do I need to verify the signature on that certificate? The CA's public key. So hopefully my browser is configured to have the CA's public key. Alternatively, I might have a certificate chain. So I might have a root CA, which has got its public key over there, which signs another certificate. And the principle of that certificate signs my certificate, HDFC Bank certificate. So you can have a certificate chain. Are you familiar with this idea of a certificate chain? So any of these things that requires further explanation will keep those things for the last day. There's a question and answer session. So just remember to ask me this if it's not clear with anyone. What is a certificate chain? I just don't want to digress somewhat and start talking about that. So on receipt of the certificate, the client checks the owner's name URL, validity period. It also verifies the signature of the CA on the certificate. So that's on the client side. Who's doing it? I am doing it. Not really me, but my browser. Then client key exchange. Now this is a very interesting step. The client chooses a pre-master secret. So this pre-master secret is chosen entirely by me. A 48 byte random number. The pre-master secret is encrypted. Now I've got this pre-master secret and we have to agree on this. So I have to send this across. How do I send it across? I've got that guy's certificate. So I will use his public key to encrypt this pre-master secret with his public key and send it across. He will decrypt it and thereby he gets the pre-master secret. So it's encrypted with a server's public key and send to the server in the client key exchange message. The server uses its public key to decrypt the encrypted pre-master secret. Now from the pre-master secret to the master secret. Another beautiful idea. Both client and server compute the master secret using the expression F. This is actually a PRF. What is PRF? Sero-random function. It's like a cryptographic hash. So a sero-random function of the pre-master secret and of the two nonces. That's where the nonces appear in the picture. Now you see that both sides have the opportunity to contribute to the master secret. The pre-master secret was unilaterally decided by the client, but the master secret has been decided by both. So your F is an HMAG style function while the constants are predetermined values known to both client and server. So far, any question? So I send, so I initiate the thing. I am the client or the customer of the bank and that's the bank. First thing I send a client hello saying that I can support these crypto algorithms and this is my nonce. That guy says I can support these crypto algorithms and this is my nonce. We decide, we will use triple S or we will use AES and we'll use MD5 and so on and so forth. And with those two nonces in place we are ready to now compute the master secret but before that I have to send the, of course I also verify the server certificate. Then what do I do? I generate random number which is the pre-master secret encrypt with that guy's public key which I just recovered from his certificate and send it across. He decrypts it and now both of us know what is the pre-master secret. Now from pre-master secret to master secret. We have exchange nonces. So the master secret is a pseudo random function like a hash of cryptographic hash of the pre-master secret and the two nonces RA and RB. And now the derived secrets. The master secret and the two nonces are further used to derive the following six secrets. The initialization vector for encrypting messages from client to server, from server to client. The secret key for encrypting messages from client to server and then again from server to client. So two different keys for this. And the secret for computing the keyed hash on messages from the client to the server and from the server to the client. So there are a total of six keys. Then there's another kind of message called the chain cipher spec message. Both parties create and send a chain cipher spec message after this business of key derivation is completed. This message signals that from now on the cipher suite just negotiated and the keys just computed will be used. So enough of this handshake business. Now we will go on to exchange our regular messages. So what you suspect will happen is I will type my password and now there's a secure tunnel. The password will be sent to the bank. The bank will verify the password. Then I will ask me what do you want to do? Do you want to transfer this account to that account, et cetera? All that through a secure tunnel. The finished messages, both sides communicate a finished message to the other. The finished message includes a keyed hash on the concatenation of all the handshake messages sent in the preceding steps plus a predetermined constant. The keyed hash serves as an integrity check on all the previous handshake messages. So the designers of SSL made some mistakes initially. For example, they forgot to do one of these steps. So the net result was that a hacker, an attacker could come in the middle and change the cipher suite. For example, instead of using 128-bit desks, he could change it to 56-bit desks and make it weaker so that he could then attack the system. So what they decided to do was take all the messages that go before, what are those messages? Client, hello, server, hello, key exchange, et cetera, all the messages before this finished thing and concatenate them with some constants and take the keyed hash of this entire thing and send that across so the other guy can verify it. If anybody is tampered with any of those messages, then the verification will fail. Now this is the important question that I asked and that is, one of the goals is to authenticate the server. The incorrect answer is you say that I just received the server certificate, therefore he's authenticated, wrong. You need to do more. So let's just see if I could explain this. So at what point does the client authenticate the server? The key used in the keyed hash contained in the finished message is one of the six derived keys. So the keyed hash on all those messages that came before in the handshake, you performed the keyed hash on all those messages and the key that was used is one of those six derived keys. Where were those derived keys obtained from? The master secret. And where was the master secret obtained from the pre-master secret? Look at the sequence of steps. I'm looking at, I, the client, I'm looking at the keyed hash that he sent me. Now he has performed the keyed hash using one of those six secrets. If that keyed hash is correct, he must have computed those secrets correctly. To compute those secrets correctly, he must know the master secret. To know the master secret, he must know the pre-master secret. To know the pre-master secret, how could he know it? Only by decrypting the message I sent him. That client key exchange is that secret that I sent him the pre-master secret which he decrypted. So he must have been able to decrypt it correctly. If he decrypted it correctly, he must have, to decrypt it correctly, he must have used his private key. And that private key corresponds to the public key in a certificate. Therefore, he must be the right person. At that point, I am sure that I'm talking to the right entity, whether it's HDFC Bank or the e-commerce server or whatever. Only at that point, when I receive the keyed hash, the keyed hash computed on all those six messages that came before on the handshake, only then am I sure I'm talking to the right person. Not by receiving, only receiving the certificate is not enough. How many browsers get? Check the certificate check. You have to, so the certificate check is multiple things. The first thing I receive the certificate, validity period. What else? I don't know, certification authority. How many browsers? How the browser check that this certificate is a valid certificate? So the first thing you do is, you look at the validity period. You look at the CA. Suppose the CA is the root CA. You are configured with that CA's public key. The CA has signed the certificate. We know how to verify the signature of the CA on that certificate. So whether that chain of getting the certificate is stored in the database of that particular browser or somewhere else? You have to send, no, no. Chain of certificates has to be sent by that guy. So this is CA1, vouching for CA2's public key. So that is the first certificate. Then the second certificate. CA2 signs this certificate, vouching for CA3's public key, and so on and so forth. And finally CA5 signs a certificate, vouching for HDFC Bank's public key. So there is a chain over there and I verify each link in that chain. Suppose today I have got that certificate for some domain. Then how I can store that? Store what exactly? You just have to- That certificate path. You don't store the path. You get the path on the fly. If I want to talk to a particular e-commerce server, he will send me, for example, let's forget the path. Let's just talk about, he's got a certificate signed by the CA, who's a root CA. Do I need any path and all? No, correct? Now the thing is, whoever signs this certificate might not be very well known. But that guy, say CA2, his certificate is signed by CA1. Should I draw it over here? Let's just talk about a path of length two. Okay, so CA1 signs a certificate stating that CA2's public key is something, something, something, something, something. And then CA2 signs a certificate stating what? So I'm dealing with HDFC Bank. That HDFC Bank certificate is, I mean HDFC Bank's public key is this, and signed by CA2. Now what happens? I'm giving a simple example of a chain of length two. I could have a chain of length one, where CA1 just signs saying that HDFC Bank certificate is, public key is this. So this is a chain of length one. Now there's no big deal. My browser is configured with HDFC Bank's public key. So I can verify this certificate. Yeah, sorry. My browser is configured with the public key of CA1. So I use CA1's public key to verify this certificate. Okay? That's straightforward enough. I have to assume that my browser is configured with the public key at least of the root, CA1's public key. Now consider this option. Now here HDFC Bank must send me this and this. So first I look at this. I can verify the signature of CA1 because I've got his public key. So I verify this. Look at the validity period and so on and so forth. Now I've got CA2's public key. So now I can verify the signature of CA2 on this certificate. And now I am convinced that this thing is HDFC Bank's public key. So I hereby certify that HDFC Bank's what? Public key is this, this, this, this. The same thing over here. I, CA1, hereby certify that CA2's public key is this, signed by CA1. So this kind of thing is called a certificate chain and this is what you would send across. If you, if I don't, if my browser is not configured with the public key of CA2 and you might have a chain of length three on four and so on. So the certification, we will question all the certificates I've found for the forwarding into the work. Yes, the entire chain. Suppose for example, and that is why you have to be very, very careful with, say, CA1 because everything under that tree will have to be revoked. Suppose for example, CA1's public, private key was compromised. The whole tree is compromised over here. Okay, so key exchange. How do we exchange the key? So one method is, what is the simplest method? What is this key exchange business? This is, as you will see, one of the messages is called key exchange. This is the sending of the key from the client to the server. Which key? The pre-master secret. Now that's the question. How do you exchange that key? What is your answer? There are some very nice options actually, but I don't want to discuss all of them right now. One thing is, I've got this guy's certificate. I just use his public key and encrypt the pre-master with his public key. So that is one exchange method. The other thing is I can come up with a ephemeral public key, private key pair. Okay, I means that guy, the server, and he could send me that thing signed by his private key, which corresponds to the public key in a certificate. The reason for this complication is that there are some certificates where the corresponding private key is to be used only for signing and not for encryption. So if he sends me that kind of certificate, then I cannot use that private key or the corresponding public key for encryption. So what I do is this neat trick. What that guy does is he sends me, he generates on the fly, a public key, private key pair, and then he signs that thing with his private key corresponding to the public key in a signature-only certificate, and he sends the entire thing across. So I will verify that public key, private key pair, and then use that public key to encrypt the pre-master secret to him. I know if this is a little confusing, leave it right now and we can come back to it later. I'm just telling you there are many methods for key exchange, because somebody had a question yesterday about key exchange, whether you use Diffie-Hellman or RSA. You can use RSA, you can use RSA in multiple ways, and you can use Diffie-Hellman also in multiple ways. We'll talk about Diffie-Hellman on Wednesday. Okay, so this is something to do with Diffie-Hellman, this G raise to A and so on. We'll keep it for a little bit later. And then the other nice thing about SSL is this idea of sessions and connections. It is good security practice to change keys during a long-lasting session. So suppose my session lasts for half an hour. It's not at all a good idea to keep those keys for half an hour. I would like to refresh those keys, say every two minutes or five minutes. SSL has provision for changing keys by creating new connections within an existing session. Now how do you do that? By far the largest component of the overhead in creating a new session is what? It is the private key operation, RSA decryption of the pre-master secret of the server. Please understand that point. Look at all the different messages. The thing that takes the most amount of time, as we know, RSA decryption is more costly than RSA encryption. Where do you use RSA decryption? The pre-master secret is encrypted by the client using the server's public key and sent to the server. The server has to decrypt it RSA decryption. That's a time-consuming operation. So these guys watch this thing very carefully and there were many research papers on this thing. Where is the overhead in SSL? And they realized if you want to refresh it or establish a new connection within an existing session, then we don't want to come up with this pre-master thing all over again. Reuse the pre-master secret, but you will get a new master secret. How? Look at the statement. I want to derive a new master secret, but retain the earlier pre-master secret that we exchanged. Now go back to the master secret. The master secret is a PRF, zero random function of the pre-master secret and the two nonces. Again, the master secret is a PRF of the pre-master secret and the two random nonces. So keep the pre-master secret the same and let's exchange the nonces again. So when you're doing that SSL, you might find this happening. That key exchange takes place once, but there are many client hellos after that. That's exactly what is happening. I'm retaining the original pre-master secret, but I am coming up with new master secrets. And those are much lightweight compared to the business of exchanging a pre-master secret and decrypting it and so on. Does anyone want me to clarify any of this? Does it make sense? So let me just clarify that thing. When client is complicated to... Yes. It's implemented in your browser. In browser? Yeah. Okay, okay. So all this hashing algorithm or that is implemented in the browser? So the question is, where is this SSL implemented? Is it implemented in some software that you write? No, it's implemented in the browser. So that's a nice thing, that you can have so many different applications which run on HTTPS, but you don't have to implement it within the application. So just to clarify this business of the pre-master secret and the master secret again, I think this equation should say it all. The master secret is a pseudo-random function of the pre-master secret and the two nonces. So once and for all, I decide on the pre-master secret and thereafter we exchange nonces every five minutes and we get a new master secret. Isn't that a great idea? Without too much of an overhead, yes. Why that transaction made through SSL are so slow? Why are they so slow? Are they really very slow? Sometime our money gets debited and we need to wait for the refund. They're very slow. That might be something in the server, the backend server. It may not be necessary due to SSL. It might be that, I'm not gonna ask you which bank, but it might be that the core system of your bank is actually very slow in doing all the database accesses and so on. Usually session gets expired during their time. I see. It's a fault of the bank. I mean, you can meet me offline and tell me which bank it is. And... Sometime I used to do with the credit card also. I see it. Not only with the case of the bank, it's always the case of credit card debit cards. Each and every bank. Yes. I'm almost willing to bet that it is not due to SSL overheads. It's not due to SSL. Yeah, it wouldn't be due to SSL overheads. Because I mean, look at how simple this whole thing is. Right? I mean, what are you doing? You're just doing one decryption for the entire transaction of the pre-master secret. I mean, that's why this thing is designed in such a way to be so elegant and so nice. And all the rest of the time you're doing secret key operations or simple hashes and so on. So it can't be too much of nowhere in the talk. I mean, if you're talking about IPsec, I can understand. There's a lot of stuff that's going on over there, but not this protocol. So once and for all, I decide on the pre-master secret and the two nonces. But again, I can change the nonces anytime I want. So at the start of this connection, I will decide on the pre-master secret. I will choose the two nonces. And thereafter, keeping the same pre-master secret, but changing the nonces, I will come up with a new master secret. What does that achieve? I've got new keys after two minutes. Again, after two minutes, I've got new keys in a very lightweight kind of way. Because all I have to do is exchange those nonces. What is the need of the constant? What is the need of the constant? Just to confuse the hacker even more. It's like a really, a redefined value pre-finance. Yes. So there is some value. I forget the exact hexadecimal value, but you just put it over there and you've computed the PRF. Usually you have to use some kind of entropy. So these are actually pre-defined because the randomness is in those two nonces. If the nonces are same numbers, will the master secret be the same or the different? It depends on if the nonces are same. It depends on the pre-master secret. So it's a function of all these three things which are all random. No, we are not getting the master secret every time. Yes. R, A and R, B are the same for the second time. Will the master secret will be the same or the different? For heaven's sake, please don't do that. The definition of a nonce means, actually what this word nonce means, use only once. That is the random number selected by the browser. Same thing this lady asked me. Those random numbers are guaranteed, almost guaranteed, if you use a proper zero random number generator, almost guaranteed to be different. Why? Because the space is so large, two raised to 128 is an incredible amount of numbers. And I'm just choosing one at random. There's almost a zero chance that I choose the same thing again. They will not be shamed any time. If you use a correct zero random number generator. Yeah. Sir, in ATM software, they are using the same thing, like we are using in browser, what? For doing transaction. The ATM? In ATM transaction, whatever we are doing, same thing is there for browser. It means it follow the same SSL and everything. Yes, yes. The moment you use SSL, it's the same thing. It's exactly this protocol. It's a standard, right? When you say standard means whenever you're using SSL, wherever you use it in a browser server, whatever, it'll be the same thing. On an embedded device, it'll be exactly the same. They might use different algorithms because that you can negotiate, but the steps and all will be exactly the same. Sir, like while we choose this random number, are there specific algorithms that help us to choose this random numbers? Certainly, certainly, certainly. There's a whole study in the algorithms course on pseudo-random number generators. Sir, any reference regarding that, so that we can refer it? I can give it to you later. I've got some of them in my computer, but I don't have them right now. Thank you. There's something that you have to be very careful about in simulations and many, many things. You have to use a proper pseudo-random number generator, and lots of research has been going on in this field for many, many years. Which encryption algorithm that is prepared in case of SSL? Which encryption is preferred? Can anybody answer that question? So the question is, which encryption algorithm do you prefer? AES? RC4 is a little lightweight, but AES is pretty good, and even performance-wise, it's pretty decent. You know, you might have encountered this thing. If you did internet banking, say, seven years ago or something, this thing would not work. It would say, it would come back with a statement over there saying, the bank enforces triple-desk. Your browser does not support triple-desk. Therefore, we cannot continue discussions. So it would just simply abort the connection or the connection attempt. So that's this negotiation process. This guy says, I want triple-desk or AES. This guy says, I can only support desk. Sorry, we can't proceed because that's not secure. Yes? Sir, when we make a website, how to make it SSL-enabled so that we can see in URL, HTTPS? When you make a website? For example, there is a small database and there is a client-server-based thing. Yes. Whatever we enter, it goes encrypted. So ensure that how to make it SSL-enabled so that in URL, we can see HTTPS to ensure that, yeah, things are going encrypted. Okay, so there is a full library to do this called OpenSSL, and you can use that entire library, and it'll give you what are the header files and everything that are needed to take your website and SSL-secure it. Yes, yes. Your application should tell these browser, right? That this website supports SSL and only SSL and won't proceed otherwise. Aphemeral Diffie Helmin. Make a guess. Come on. Aphemeral between anonymous, static. Yeah. Could you differentiate? So I'm going to actually talk about Diffie Helmin in great detail in the next section on cryptography. So how we get this G-Race to A, but if you want me to answer your question in a minute, can you imagine a certificate with the Diffie Helmin key in it? I'm sure most of you have seen this thing. What is this G-Race to A and G-Race to B and so on? This is the first idea of public key cryptography. I would like you to just think about the idea of using Diffie Helmin for this public key infrastructure. The question then is what is the public key? Put that public key in a certificate and just try out all of this. What do you think would be the public key? Without getting too detailed in this thing because I have to complete some things. What is the public key in Diffie Helmin? It would be G-Race to A and A would be the private key. Imagine putting G-Race to A inside your certificate and signing it. So that is fixed Diffie Helmin. The other thing, a female Diffie Helmin would be you generate your G-Race to A, your P, the prime number, the G and the G-Race to A and you send the G-Race to A across but don't forget to authenticate it by signing it with your RSA private key for example. So that would be a female Diffie Helmin. So there are various versions which can be used for fixed, for key exchange methods. Okay, so we'll elaborate upon those things when we talk about the discrete logarithm problem and Diffie Helmin key exchange, et cetera, in the next session on cryptography. So just to answer your question in a nutshell. Why is here key that H-MAC style function? That F, that's basically PRF. That's basically a PRF, zero random function. No, H-MAC, why not is a MAC style? Only why is the H-MAC style function? H-MAC is the most secure version of the MAC. That's why it is taken. If you look at the H-MAC thing in the textbook, you see the formula for an H-MAC, it'll involve multiple MACs out there. And computing the MAC in general is not very time consuming. Sir, how this SSL is working on the mobile applications? Is there any kind of different procedures applied? Or same as procedure applied? What is a mobile application? What is a cell phone? Not of banks having currently the... I'm just asking you a question. When you say cell phone, when you say smartphone, what is the difference in a smartphone and a computer? Nothing. Today's smartphone is basically a computer, right? What is it you can't do? Then that certification exchange and same thing. Everything the same thing. Sir, sometimes when I try to do the bank transaction, so the browser may not support whatever pop-up menu I'm going to get. So they'll be getting a certificate saying that you want to proceed or you don't want to proceed. If you don't want to proceed, you are in risk. Suppose if I go away, the option, no. Still I'm able to do the transaction. Now here, we are implementing many securities like certificate, next password. And after password, now they are come out with new thing. That is, they are asking some personal details. So if it is valid, then it is moving to the next. So this is an interesting question. Which is important in this case, which has to be given priority so that the transaction is going to happen. So the browser is just trying to help you. He's basically what that comment means is that the browser is saying that this certificate is signed by a CA that I don't know enough about. Do you still want to trust that CA? It's up to you. You want to trust, we can proceed. If you don't want to trust, then I'm sorry we can't continue with the transaction. So that certificate chain stops at a certain point and the browser's not configured with that subtree. The root of that subtree, the browser is not configured with that public key. Now here in this case, if the certificate has to be sent by the bank people only. Yes. So suppose if it is not being trusted and then still I proceed further, so why it should accept when it is not sent by the bank people? No, no, it is sent by the bank. It's just that tree, that chain of certificates, the root of that tree, you see the tree doesn't, it starts at a certain point, right? Now typically what would be done is you'd have a chain that ends at the tree. Now the chain need not end at the tree, it might end at the subtree. Okay? So if it ends at a subtree, I may not know at that level what is the CA's public key. I means the browser. So now the browser takes a risk, right? So it doesn't want to take the risk completely, it says you decide, are you willing to accept that, if the chain stops over here? It doesn't say all that because most people don't understand what is PKI and so on. But basically that's what it means. It says that the chain stops over here and I don't know this guy's public key. If the chain stopped over here, that's fine, I'm configured with that thing. And one more, sir. So here it will ask for changing the password for every 15 days. And it should not be the same. And like this if you go on after 365 days, just imagine how many times we are going to change the password and we have to remember all of them. Again we'll forget. I told you on the very first lecture that security is also trade-off. Trade-off of security versus convenience. Yeah. So unfortunately there's certain things to be, you know you have to bear certain things. However, this business of changing the password 15 days is not a good idea. There are many other words like one-time passwords, other solutions like one-time passwords and so on. So instead of going with different algorithms, why can't we just log in and immediately give a chance for changing the password so that we go for a new one? Just log in and change the password. Anybody can see the password, right? No, whenever we try to log in. Your new password has to be sent across a secure tunnel. Yeah, correct. With that, what can you do? You need something like SSL. Password business, you only need SSL. So we are totally concentrating only for the login? No, not only that, even the transactions, right? Suppose I log in with my correct password and somebody hijacks my connection, okay? And then sends a, you know, transact that is transfer from this account to that account on my behalf. Will it be okay? Obviously not. So every single message has to be integrity protected and authenticated. Thank you. Okay, so finally to conclude SSL, so you're gonna have a lab where you will see all of these SSL messages and every field inside those SSL messages. I hope you will enjoy it and learn something from it. OpenSSL is open source software that implements the SSL TLS protocol comprised of a number of libraries that implement various cryptographic algorithms. So this is something that you can use liberally in designing your applications which require security. In addition, it provides extensive support for creating, communicating, and validating digital certificates. It's based on a library by Eric Young and Tim Hudson. So if you're writing applications, this is the place you need to look at for them. You have a quick question, we can just attend to it and then continue with software security. Sir, most of the time when we are performing the transaction through credit card, the user have to enter the credit card number and three-digit number through virtual keyboard. So if you're using the normal keyboard, is there any problem or any problem of probability of trapping the customer or something like that? If you're using the normal keyboard, 100 things that can go wrong. I told you that even the sound of the keyboard, the frequency or the time interval between the typing of keys and so on gives me hints about what you're typing. I mean, if you really want to crack things, there's no limit on such things, okay? I mean, keyboard and so on. So a virtual keyboard has more security than a physical keyboard. On the last day, we were talking something about the side channel attacks that my students are working on over here and you will see that even cash systems that are supposed to be presumably secure can be highly insecure and you can get AES keys from them. So there is no such thing as perfect security. Just to add the water, you said, even virtual key can be hacked. In the sense, we can observe the position of the click. So that's why the virtual key, you can observe that the virtual key will be random. They randomized the virtual key, even that, so. Right. And if you're on an ATM booth or something, they can put a camera over there to see what you're doing. So I mean, there's a number of different things that you can hack into. So security can never be 100% complete. It's only relative that this thing is secure.