 So, welcome back to day 5 session 2 the focus of today's discussion is on actually multiple things first we start with key management then we will have a demo of buffer overflow and then we will have a short quiz for about 20 minutes after which I will announce the answers. So, let us begin with our discussion of key management let us see what is the problem exactly that we are trying to solve over here. So, let us suppose that A would like to send a message to B a secret message to B a confidential message to B now for that purpose he needs to encrypt it and let us assume for the time being we are talking about public key cryptography. So, you are trying to send a message to B you need B's public key. So, what you do is you request B give me your public key you get the public key and then you encrypt the message with B's public key. Now what would happen if by chance A's message were hijacked by somebody and that somebody gets this request let us say the attacker gets this request and sends back his own public key to A. So, the attackers public key now A thinks that is B's public key A encrypts the message with the attackers public key and the attacker reads it and responds to it B is nowhere in the scene. So, once again I will just repeat A wants to communicate to B in a secure confidential fashion. So, A requests B's public key the request message which was supposed to go from A to B gets hijacked by the attacker. The attacker then inserts his own public key into the response and sends it to A and then A uses the attackers public key to encrypt the message. Once again the attacker receives it he can decrypt it because he has got his own private key and as you can see the problem over here is that there was no authentication of the response message from B to A. B should have in some way said this is my public key, but with the fact of the matter is I do not know from the message that I received whether it is really B's public key or somebody else's public key. So, for that purpose we use digital certificates and so digital certificates comes under the realm of key management. So, I mentioned before digital certificates, but I did talk about certificate chains, but not in great detail. So, in this the next few minutes I would like to clarify some of these ideas. So, when the public key reaches A, A should have some means to verify that this is indeed B's public key and not somebody else's public key. So, how do we guarantee that? Key management is related to the generation storage distribution and backup of keys. Our focus will be on the management of private key or public key pairs. So, the problem statement to encrypt a session key for use in communication between A and B. A needs to know B's public key as shown in this picture. Likewise, to verify B's signature on a message A needs B's public key. So, you need somebody else's public key for it for at least two reasons and probably three. The first reason is to encrypt a session key to send to him using his public key. The second is to verify his signature on a message and of course, the third could be for authentication. So, fundamental question is how does A know B's public key? So, each of these things as you can see, I need to know B's public key. Here again, I need B's public key. An authentication to verify the response to the challenge, I might need B's public key. How do I obtain B's public key? So, one approach could be something like maintain every person's public key in a centralized repository or a distributed directory. So, something like a centralized or a distributed store. It could be for instance a website and you can just go there and say I want, for example, Bill Gates public key. Now, there are problems with this approach. There are scalability problems associated with a centralized solution. If everybody starts asking for somebody's public key from that centralized server, there could be problems. So, of course, you can mirror it and so on and so forth and reduce the probability of congestion. The other thing is, the directory service could become the target for various attacks like spoofing, denial of service, etc. There are also problems with the non-uniqueness of names. So, I say that I want, let's say Rajesh Singh's public key. But the question is, there are so many different Rajesh Singh's, probably hundreds in India, for example, with people with the same name. So, there is a non-uniqueness of names. So, there are several problems with this either centralized or distributed approach that I just mentioned, going to some website or a bunch of websites and asking for somebody's public key. So, is there another solution? And again, this is not a solution without problems of its own, but at least this is one solution that seems to be working today. And that is the use of digital certificates. As mentioned before, so this is more or less a review. A digital certificate is a signed document used to bind a public key to the identity of a person. Who is it signed by? So, this is a binding. So, somebody states that A's public key is the following. And then that person signs the document. So, that document is basically the digital certificate. Now, we use the word identity over here. So, the individual's identity, what is it? What comprises an individual's identity? It could be his name, it could be his email address, postal address, etc. Any combination of these things that is unique for an individual. So, in some countries you have the national identification number or social security number, etc., which uniquely identifies a person. No two people have the same national identification number, for example. Certificates may be issued to individuals, to organizations or even to servers. So, web server can have a certificate as we have seen in the SSL protocol. It can be, of course, individuals. It could be organizations. So, verisign has a certificate or certain company X, Y, Z has a certificate, etc. The entity that issues certificates is a trusted entity called a certification authority. So, CAs are often selected government agencies or banks. Basically, somebody or something that is trusted. There are also different types of certificates. The most basic type can be requested through email from the principal or from the subject, from the holder of the certificate to the CA. So, you can, through email, for example, request from a certification authority. So, there are different types and levels of these certifications. So, you can request a certificate from a CA, a very basic certificate. Now, what does the CA need to do to give you a certificate? At the very least, the CA needs to verify your identity. And if you want to get more fancy than that, the CA should verify that the public key that you claim to have is related to the private key that you have kept securely. So, you are not going to tell him the private key. You are going to only tell him the public key, but there are times where the CA needs to verify that you have the corresponding private key. Notice that with RSA and DSA and so on, the public key and the private key have a mathematical relationship with each other. So, basically, what you are doing is you are taking the public key in an email and you are saying, Mr. CA, this is my public key and these are my credentials. Now, the first thing the CA will do is, he will try to verify your identity. Are you really the person you claim to be? Is this your address? Do you work for this company? Some basic information, just to identify you, sort of. But then, he could get a little bit more detailed. He could say, this is your public key. So, presumably, you have the private key corresponding to that public key. Now, can you prove that? So, now, that gets to be a little bit more fancy. How are you going to prove that you are in possession of that private key? But this is an option. The CA does not have to do that. If you have a higher level certification, then, of course, he should do that. But for a most basic kind of certification, it just suffices for him to verify just your identity. So, most types of certificates require the CA to perform identity verification of the applicant through submission of a passport, driver's license, etcetera. The CA may have to obtain and verify details of the applicant, such as his employer, email address, etcetera. Practically speaking, this task would be delegated by the CA to a registration authority, because the CA might get overworked. So, he might have several registration authorities under him who can undertake this task. Now, what does the certificate look like? So, most of you are already familiar with it. So, we just review this. There is a certificate serial number and a version. So, the certificate standard is the standard that defines the format and the content of a digital certificate, the X dot 509 digital certificate format. What else does it contain? Issuer information and subject information. Who issued this certificate? Which is the organization that issued it and to whom? So, in both cases specify the name of the person, the name of the country, state, organization, email address and some such other details that are enough to identify that individual, both the individuals, the issuer and the subject. Then other important fields, very important, the subjects, public key information. Now, there could be different kinds of public key algorithms and algorithms for signing. For instance, for signing you can have an RSA signature or you can have a DSA signature. DSA stands for digital signature algorithm, which is a variant of El Gamal's signatures that we talked about some lectures ago. So, when you talk about subjects, public key information, you include what things? You include the public key. You include the name of the public key algorithm, RSA, DSA, EC DSA, which is elliptic curve DSA and so on and then the public key parameters. So, in the case of RSA signatures, the parameters of the modulus and just the modulus while in the case of DSA, it would be the modulus plus the generator. Besides public key information, you have validity information. There are two date fields which specify from which period, from which point in time, the certificate is valid and to which point in time, it is going to be valid. So, the start date and the end date and then finally, the signature of the CA. So, the CA signs it, what is that signature? Give me all those bits that comprise the signature and which algorithm did he use to actually sign it. There are some other fields also in a certificate. For instance, the CA might want to specify the use of this certificate. Is it used for signing? Is it used for key exchange, for authentication, etcetera? The domain of use, is it used for financial transactions? Maybe for the, I want to keep my financial world separate from my professional world. So, is this used for financial transactions, banking, trading, etcetera, etcetera? Or is it used for my professional work? So, the certificate information, such as address, company, maybe even your photograph, etcetera. So, in the context of certificate chains, this picture is quite useful. So, what does this picture actually tell you? It tells you there is a root CA in this tree of trust. So, this is one possible topology. So, there is a root CA, the line between the two indicates that CA 1 trusts CA 2 and vice versa. So, it is actually bidirectional, CA 1 trusts CA 2, CA 2 trusts CA 5 and so on and so forth. So, basically what this means is that CA 1 has issued a certificate on behalf of CA 2 and signed that certificate. CA 2 issues a certificate on behalf of CA 5 and CA 5 issues a certificate on behalf of you too. So, these are regular users, while these are certification authorities or registration authorities. Now, let us consider the case, where U 8 needs to communicate with let us say U 2. So, U 8 needs to communicate with U 2, for which purpose U 8 needs to communicate a session key and for that purpose to encrypt the session key, he needs to have U 2's public key. So, now what should we do? U 8 needs to have U 2's public key. Now U 2 can send the certificate signed by CA 5, but as you can see from this picture U 8 user 8 does not know anything about CA 5, there is no relationship of trust or even he is not even aware, this guy U 8 user 8 is not even aware of who CA 5 is. So, for U 2 to produce the certificate signed by CA 5 is meaningless as far as U 8 is concerned, what U 2 needs to produce is an entire certificate chain. So, what U 2 will do is it will provide a certificate CA 2 certificate signed by CA 1 and also CA 5 certificate signed by CA 2 and also his own certificate signed by CA 5. So, this is called the certificate chain, I mentioned in some of the authentication protocols that you might send a certificate or the certificate chain. So, this is the chain of certificates 1 certificate 2 and 3 as far as U 2 is concerned. Now, as you can see in this picture there is a relationship of trust between U 8 and CA 1 and trust is transitive. So, if this guy trust this guy and this guy trust this guy then this guy trust that guy. So, U 8 is well aware of CA 1, so when he receives the certificate chain what he does is he first takes this certificate, the certificate of CA 2 signed by CA 1 and verifies the signature of CA 1 on CA 2's certificate. So, from that he gets CA 2's public key because the certificate that CA 2 has is a binding between the identity of CA 2 and his public key. So, from that he extracts out CA 2's public key. Now he has a certificate signed by CA 2 on behalf of CA 5, he takes that certificate which is the binding between CA 5's identity and his public key, he takes that certificate he verifies whether the signature is authentic or not because he has now CA 2's public key. So, he verifies the signature of CA 2 on CA 5's certificate issued by CA 2 to CA 5 and from that he pulls out CA 5's public key and finally, in this chain CA 5's public key on behalf of U 2. So, he verifies CA 5's public address sorry public he takes out CA 5's public key and verifies CA 5's signature on that certificate and thereby he knows for sure that U 2's public key is what is contained in the certificate from CA 5 to U 2 that is how he obtains U 2's public key and he is convinced now that this public key is authentic. So, this is in words what we saw in that picture. So, CA 1 is the root CA it vouches for an issue certificates on behalf of its next level CA's in the tree that is 2, 3 and 4. So, 1 vouches for the identity of 2, 3 and 4 and issue certificates on behalf of them 2 issue certificates on behalf of 5 and user U 1. So, 2 on behalf of 5 and user U 1 then CA 5 issues certificates on behalf of U 2 and U 3, CA 5 on behalf of U 2 and U 3 and so on now the same example if U 8 wishes to communicate with U 2 and requires U 2's public key as a result then U 2 would send a chain of certificates basically a certificate of CA 2 signed by root CA, CA 1 a certificate of CA 5 signed by CA 2 and finally, a certificate issued on behalf of U 2 by CA 5 and I also mentioned how the verification takes place you start with CA 1's public key which is hopefully in your browser configured by your browser use that to verify CA 1's signature on the certificate issue to CA 2 and so on. So, many of you or most of you have heard of this term PKI the public key infrastructure. So, what exactly is this the PKI includes the certification authorities all the physical infrastructure including encryption technologies hardware etcetera also the formulation and enforcement of policies and procedures. So, it is a bunch of all of these things and includes the following services certificate creation issuance storage and archival. So, it will issue you a certificate it will store it securely and archival securely for you key generation and key escrow will come to what this means key generation and key escrow if necessary. So, there are chances if your organization issues you a certificate it will actually also issue it will also generate the public key private key pair for you, but in general a CA does not generate a public key private key pair this is a general statement. In certain cases especially if the public key private key pair is used for encryption then you might have key escrow in an organization. So, this is an option similarly certificate key updation is an option and finally, another task that it has is key revocation we will see why we need key revocation what are the circumstances for which we need key revocation. So, key escrow an employee who loses his decryption key will be unable to decrypt the archives of sensitive data he might have accumulated. Let us suppose that you have a public key private key pair in an organization would you generate the private key public key pair over the organization do it. Once again it depends on what you use that key for if it is used for encryption decryption then the bad news is if you actually by mistake lose that key someday the private key you will not be able to decrypt all of the sensitive data you have accumulated over the last couple of years and then what happens this is all important data of the company which you have been accumulating it is not exactly your property it is the company's property. So, for this reason the PKI within an organization might hold the private key in escrow they may be securely backed up. So, this key is a private key nobody should be able to see it other than you. So, we guarantee that we hold it in a secure fashion we meaning the organization. So, it is securely backed up and made available to the owner or to a trusted authority such as a law enforcement agency under special circumstances. So, only if there is a necessity if there is an emergency you will get it if you have lost it for example, or for example, law enforcement needs to check and see what those archives contain if there is any suspicion on what they contain. Now, these are two architectures that have been proposed and have been deployed one is the hierarchical the tree based approach that we just showed you and the other is a mesh based architecture. So, here there is a root CA which is trusted by everybody and there is a much more diffused or distributed architecture like this once again these lines are lines of trust that is there is trust from this guy to this guy and vice versa. So, in order to verify anybody's public key all you need is to find a path in this graph from say u 1 to let us say u 4 it will be a path like this or perhaps they could be another path sometimes. For example, if you want to go from here to here they could be one path like this and they could be another path through CA 3 through CA 2 or through CA 3. So, the certificate chain in this case would be this thing or it could be this thing and finally, the issue of revocation. So, why do certificates at all need to be revoked? So, there are two scenarios that I present before you suppose the validity period of an employee's certificate is 1 1 11 to 31 12 11 and now suppose. So, the year 2011 suppose the employee resigns in the middle of the year say sometime in May. So, from that point on his certificate should not no longer be valid. So, he cannot sort of for example, be using the private key corresponding to the public in the certificate for signing on behalf of that company. So, his certificate should be revoked if he tries to sign any document on behalf of the company after he resigns that document should not be valid he is not supposed to do that for that purpose his certificate should be revoked. So, this is one revocation scenario another scenario suppose the employee's private key was compromised again in the middle of the year from that point on his certificate should not no longer be valid if somebody else has got his private key that person can sign on his behalf. So, obviously that signature should not have any validity now the way to handle this one way of handling this is to revoke the certificate, but how do we do that? So, there are different ways of there are different suggested ways one is an online facility that provides information on the current status of digital certificates. So, the moment that person has left the company then his organization will contact this online facility to say no longer should that certificate be declared as valid even though nominally the validity period is the entire year 2011, but after he resigns it should not be valid. So, that information can only be maintained in an online way or at least this is one way online it cannot be included in the certificate obviously, because we do not know when he is going to resign the certificate is valid throughout the year 2011, but suddenly he resigns in the month of May. Now, this online facility to an extent nullifies the principle advantage of using digital certificates in the first place what was the purpose of using digital certificates I do not have to go online to find out that person's public key. If you think about it the public key came in inside the certificate I did not have to approach a third party and now you are saying to handle the revocation problem you actually have to go to a third party the online facility. So, this is somewhat of a drawback of this approach and the second solution is to disseminate what are called certificate revocation lists. These are lists of revoked certificates which are periodically distributed. So, if CRLs are distributed too frequently they consume considerable bandwidth on the other hand if they are distributed infrequently information on recently revoked certificates may not reach out in a timely fashion to those who need it. So, this is a brief discussion about revocation there are more details and examples in the text in chapter 10. So, with this I conclude the introduction to PKI and key management.