 So let's just summarise what we know about certificates. What's the important information contained inside a certificate? Inside my certificate is my what? My public key. We use certificates to distribute public keys. Our problem is, when I receive someone's public key, I want to be sure that it is theirs, not someone else's. So remember, your certificate contains your public key. Who has a public key? Hands up. Who has a public key? Right now, on your computer, in your head, you do where? Somewhere in the computer. Somewhere in the computer. Okay, your homework. Generate your own. Okay, so your homework task. Task one, generate a public key. Or more specifically, generate a pair of keys. A public and private key pair. So in fact, that's the first homework task. You generate, just make note, we'll see it in the homework description. You generate your own key pair. P-U-A and P-R-A. How do you generate your own key pair? What algorithm may you use to generate a key pair? Again? What algorithm may you use? Don't you answer, because you've done the homework. Someone else. What algorithm may you... again? A-E-S. A-E-S, no. A-E-S is a symmetric key algorithm. Key pairs, public key cryptography. What algorithm have we... we've gone through two. One of them, the first one we went through was RSA. RSA is the most common algorithm used for public key cryptography. There are others, but we will use RSA. So when I say generate a key pair, you use the RSA algorithm to generate those values. And you've studied the algorithm. Remember, you go through those steps. Choose two prime numbers, P and Q. Multiply them together to get N, the totion of N and so on. There's some steps for generating the key pair. So in fact, you do that. But in your homework, you don't have to do that manually. We'll use some software to do it for us. You generate your key pair. But we want to use the certificates so that someone else knows that that public key is yours. So what do you do next? Once you have your key pair, how do you get a certificate? And as a hint, let's say you trust me. You send a request to me. What are you going to send to me? You tell me who you are. You send me your identity and your public key. Okay, that's the idea. A certificate is a signed public key. So your certificate contains your public key. So what you do once you've generated your key pair and you can use some software to do that, you come to me and say, here's my public key and here's my identity to prove who I am. Your ID card or your name or something. So I can confirm it's you. So the more formal way we describe that is you create a certificate signing request. You want a certificate and you want a trustworthy person, a certificate authority to sign it for you. A certificate signing request, CSR. That's the name it's used in the homework, in the software that you'll use in the homework. It's called a certificate signing request which really is just your public key, your identity and really a message that's sent to an authority saying, please sign this for me. And it's up to the authority to confirm that this is you. So it's the role of the authority to confirm that this certificate signing request is a valid one. So you'll send a CSR to a certificate authority. In your homework, I have some software acting as the certificate authority. So what you'll do in your homework, is generate your key pair, generate a certificate signing request and you'll use some software that would do that for you which is create some message in a particular format such that when you send it to the CA, the CA gets the request and checks. Make sure it's from you. So that's the important part. The CA should confirm this is from you, it's not for someone pretending to be you. What does the CA do? If it confirms it's you, what do they do? What am I going to do? I send back your certificate. I issue you a certificate. And that certificate is your public key signed by me, signed by the authority. So the next step, the CA issues a certificate. Let's say we'll call it C of A. The certificate of user A, U. And it's signed using the authority's private key. Remember, we signed something by taking the contents, taking the hash of the contents and encrypting with the signer's private key. And the authority sends that to you. Or in general, sends back to A. What happens next? If you're user A, what do you do next? I have a guess. What are you going to do next? Sorry? Send to B. Before you send to B, you're one step ahead. Decrypt using the public key of authority. Verify. If someone sends you a certificate, including the authority, confirm, is this really the certificate? Verify. If it was signed by the authority, then when we decrypt with the authority's public key, we can verify. So the next step, before we use this certificate, we should verify. Even though it's from the authority, we should verify. And any certificate we receive, we should verify. And to verify, we need the public key of the authority. Remember, if it was signed by the authority, to verify, we need the public key of the authority. Signing is encrypting with the private key. Verifying is decrypting with the public key. And this comes back to this assumption that user A trusts the authority. Which means the user A has the public key of the authority and knows that it is the authority's public key. It's not someone else's. Now, the next step, when A wants to communicate with B, A sends their certificate to B. Assuming B has done the same thing, they send their certificate back. A sends their certificate to B. B sends its certificate back to A. That is, we exchange certificates. This assumes that B has also been issued a certificate in the previous steps. Prior to this. We're issued certificates by an authority. Once everyone's issued certificates, then they exchange them if they want to communicate. Then what? When you receive B certificate, what are you going to do? You just receive B certificate. What do you do? When someone sends you a certificate, what do you do with that? You verify. So always verify what you receive. Don't trust what someone sends you. In the homework, if someone sends you something, maybe someone intercepted midway between the sender and you and they modified. So don't trust what you receive. Verify. So verify B certificate. How do you verify B certificate? What do you need? Again, you need the public key of who signed that. In our simple case, we're assuming it's the same authority. There's just one authority in the system. The authority signed A certificate and Bs. So we verify using the same public key. In a more complex system, there may be a hierarchy of authorities. So we need to obtain the public key of the authority that issued this certificate. If someone else issued CB for A to verify, we need to find that other person's public key and be sure it's the correct public key. So in terms of exchanging certificates, we're done. Once they're issued, we exchange them and verify. But then if we want to communicate securely, now I want to send B encrypted file, then the most common application of public key cryptography is now to not encrypt using public keys, don't encrypt the data using public keys, actually choose a secret key, encrypt that, and then encrypt the data with the secret key using something like AES or some symmetric key cipher. So the next steps depend upon what you want to do. I will not list them here. They're the general ways for exchanging certificates. And that's what you need to do in your homework. So you'll read through this, but we're going to use OpenSSL to do all this for us. Instead of having to generate the keys ourselves, we'll use some software to do it. So create your own key pair, in this case using RSA as the algorithm, a 2048-bit key in this case. And here's the command to do it. So I give you the command using OpenSSL. Create a certificate signing request. So this creates a message which is structured such that the authority, when it receives it, can sign it easily. So how to create a signing request. Send that to the authority. When you create a signing request, it usually contains a set of fields like the country. This is something that identifies you, the country, state, organization. The common name it's called, for example, your student ID in the homework specifically. Use your ID. Send the CSR to the authority. And in the homework, you send that by uploading it to the server. So you need to check the instructions for how to send that. When the authority receives your request, they will issue a certificate. They'll create one for you and send it back to you. And again in the homework, they're sending back to you is that they put the certificate on a website and you can download it. And then you verify the certificate. And again, to verify the certificate, you need the public key of the authority and the public key of the authority is stored in the certificate of the authority. And the command to verify is given. So you can run the command to verify the certificate you received. In the homework then, okay, your A, who's B? In the homework, you're allocated a partner. So that's the B that you're going to communicate with. So once you're issued a certificate, there'll be a file that tells you who your partner is. So you need to communicate with your partner. So you download your partner's certificate and verify. That's like B sending them, sending to you their certificate. And then use a secret key to encrypt some data to send to your partner. Generate a random secret key and use AES. And the later instructions explain how to use AES. But that's what you've used in the first homework. You've used AES already. So some of this is repeated from before. So, and then it goes up to step eight, and then you're done, I think. So do this homework because it gives you some practice of using certificates and also gives you some examples of the specific formats and the commands that you can use to generate key pairs, generate certificates, and encrypt using those certificates and keys. When's it due? Next Tuesday, okay? Try it. Once you've tried it a few times, you get a chance to try again if you do something wrong. The software of the authority and of your partner will return some error if you do something wrong. It's a little bit cryptic, but if you read through the instructions, you'll eventually get there, eventually. Some people have finished already, okay? So it's possible to do it in a short amount of time if you go through those steps and follow them clearly, accurately. Any questions about certificates? Remember the basic concepts. A certificate contains your, your certificate contains your public key. The purpose is so that someone who receives your public key can verify it's yours. It's not someone else's. It's not someone pretending to be you. To do that, we issue the certificate from some trusted authority. What did we see last week? These few slides summarise, summarise those steps that we just wrote on the screen. These two slides, or two or three slides I'm about to go through, are from that printed handout on firewalls, I think, towards the back there. So there are just a few extra slides. Just let me check. So if you've got your firewalls hand out, these are towards the end. So in summary, this, this specific example was with respect to a web server. We saw last week an example when you access a website, the server sends you its certificate. How does that work? The server creates their key pair. They confirm their identity with the authority. The authority issues a certificate by signing it. So the general concept is, we have the identity of the server, the public key, a timestamp, indicating how long this certificate is valid for, and the signature component. All of that information hashed and encrypted with the private key of the authority. That's the concept. The format that you're using in the homework, and is commonly used in the internet, is called X509. That specifies the format of the certificate. So step one, the server or a user obtains a certificate, and then with respect to web browsing, the server sends the certificate to the browser. You visit HTTPS, colon slash slash www.abc.com. That server sends you their certificate, and the browser verifies using the public key of the authority. So when the browser receives the certificate, it verifies, and to verify it needs to know the public key of the authority, which is normally stored in a certificate as well. And that's where we get to a self-signed certificate. A self-signed certificate is one where the public key is signed by the same person as the owner of the public key. In this example, the self-signed certificate of CA includes the public key of CA signed with the private key of CA. So they signed it themselves. We need that at the top of the hierarchy if we have a chain of certificates. So we've saw some examples last week when we visited a website, and you get those warnings if it's a self-signed certificate. If it's signed by an authority, then it passes clearly. Any questions on certificates for your quiz? We'll ask some questions about certificates, the concepts in the quiz. When you access some games, if you want to download games from an Android market, then often they may be signed. So you can verify that it is the correct game, or that it's approved by someone, then again, certificates are used when accessing websites, but downloading software. So different applications will use certificates for authentication. Any questions before we move on? Last two slides, X509, again, the format. We saw some examples last week of the fields in that certificate. In practice, in the internet, when we access a secure website, they send your browser the certificate. What are some issues? How did the server obtain a certificate in practice? Well, what the server did, or the owner of the web server, they went to an authority and said, I own this website. So there's some validation of the domain. So if you are running the server for www.abc.com, then to get a certificate, you must prove that you own that domain, or the administrator of the server that runs on that domain. So there's some validation steps. There are some free and commercial services that act as authorities that will issue a certificate. Some you have to pay, some will do it for free. What about your browser? When your browser receives a service certificate, it needs to verify using a certificate of an authority. Where does the certificate of the authority come from? Most browsers have them preloaded. When you install Firefox, when you downloaded Firefox and installed it, it comes with a list of authority certificates already. So the browser developer has created a list already and preloads it into your browser. So you implicitly trust all of those authorities which are preloaded. We saw the example last week. We can have a hierarchy. The server certificate is signed by one authority, which is in turn signed by another authority in the hierarchy, one hierarchy. If you visit a website and receive a certificate and the authority that issued that certificate doesn't have one preloaded in your browser, then usually your browser presents some warning. And we saw that last week where we visit that website and it says are you sure you want to continue? And then it's up to the user. In summary regarding the security of digital certificates, some of the issues that can go wrong. When the server is issued a certificate, the authority must verify their identity. How do they do that? Well, there are different levels of verification or validation. So one thing that can go wrong is that I go to an authority and I say I own www.facebook.com if the authority believes me, because I don't own that, if they believe me, they'll issue me a certificate for that domain and now I can do man in the middle attacks on Facebook's access to their web server. So this verification of the identity of the server and the server owner is one thing that needs to be done correctly. The authority signs a certificate using the authority's private key. Whoever has the authority's private key can sign certificates. So the private key of the authority must be kept secret. If someone discovers the private key, then they can issue fake certificates and therefore perform attacks. So that's another issue that we must make sure that the authority's private key is kept private. If it's not, then the system can fail. Your browser, the developer of your browser preloads a set of certificates into it. So they choose a set of authorities that they trust. If they preload a certificate in there that is not trustworthy, then that presents problems for the end user. So you must trust that the browser publisher has adequately checked those preloaded certificates. If you look at your browser and see you can usually see the set of certificates that are available. So we'll not go through if we look at the tab authorities. We'll see that preloaded into my browser tens of possibly 100 plus authority certificates from many different organisations. So these must be trustworthy. The publisher of the browser must make sure that these are coming from trustworthy organisations. If not, then it's possible for websites to or attackers to do man in the middle attacks on your web communications. We saw an example. What happens when you visit a website and the certificate is invalid? Well, it normally presents a warning saying untrusted connection. Then, well, I suspect some users normally say let's trust it anyway. But that could be a sign of a man in the middle attack and may mean that someone's intercepting your data even using HTTPS. Of course, the algorithms used inside the certificate should be strong. That's normally the case today. And that finishes on our topic of key distribution, key management and closing with digital certificates. How do we distribute public keys? Well, we have them signed by an authority. Any questions before we move on to our next topic? Everyone okay for the quiz on public key management? Yes, okay. You can't use your laptop in the quiz. Okay, let's close this one.