 So the approach to overcome this performance problem with the authority is to use what's called public key certificates or simply certificates. And this is maybe, this picture may be a little bit confusing or it's hard to compare with the previous one, we'll explain why. Note the number of messages. It looks similar. We have user A, user B, an authority, just call it a different name. Here we have user A, B, an authority. In the use of the public key of the authority, every time A wants to talk to B, there's a request to the authority and a response in message one and two, and B must send a request to the authority and get a response in four and five. So every communication between pairs of users require messages to the authority. With a certificate authority, that's not true, and that's why this diagram is a little bit misleading. We'll redraw it in a moment. Whenever A wants to talk to B with a certificate authority, the only two messages we need to send are one and two. The other messages drawn on this diagram are exchanged in advance manually. So maybe you note on your slide that the message from A to the authority and the response. So make a note now on your handouts so you don't forget when you study for the exam. The message from A to the authority and the response, and B to the authority and the response are manually exchanged. They not automatically sent across the network. Draw on your handouts. If you didn't bring your handouts, you'll get this wrong in the exam. So note carefully that one and two are sent across the network, whereas with the public key authority, all seven messages are sent across the network. And if you can recognize the difference there, you'll see with a public key authority, every time two users want to communicate, some messages go to the authority. That's a performance problem. With a public key certificate and certificate authorities, every time two users want to communicate, only messages go between those two users. Nothing goes to the authority. And that's the advantage here. It's a performance and convenience benefit. There's no additional security provided, so it's an improvement on performance. So how does it work? Why do we only need to exchange between A and B, not between the authority? It deals with what we exchange manually in advance. I'll try and draw the diagram again, but highlight which ones are manually exchanged and which ones are automatic. So initially, I will highlight what's known and what's assumed up front. So we have user A and user B want to communicate. And we have an authority, I'll denote as the certificate authority or simply CA for short. The certificate authority is CA in this case. The manual exchange is that if I'm the authority and you're the users, we said before, you come to me, you come to my office and give me your public key. Same thing happens here. The user goes to the authority and gives them the public key. But what's different compared to the public key authority, the certificate authority issues the certificate. So we'll see the structure of that certificate. So the manual exchange is that A goes to the authority and gives, shows the public key of A to the authority. So we'll record what's known, let's be clear that A knows its own public key and its own private key, B knows its own public key and private key. They have their own pairs. So the authority has its own pair. And in the manual exchange, A gives its public key to the authority and the CA, the authority gives its public key to the user A. And similar, there's a manual exchange between B and CA. This is the same as with the public key authority, there's nothing different yet. Each user goes to the authority, they exchange their public keys. Must happen in advance. But also in that exchange, when the authority gives A its public key, the authority gives A another piece of information called the certificate of A. So I'll simply list that as CA here. The authority issues the certificate to user A. A certificate is like a document that is signed. So the document in this case is the public key of user A and it's signed by the authority. Similar, when B goes to the authority and they exchange public keys, the authority issues the certificate to B, CB, we'll need some space to write it down. What is inside the certificate is important. And it's on the slide, maybe we'll look at that. This is the issuing here. So again, this is the manual exchange, A gives its public key to the authority. The authority issues a certificate to A. CA here. What is the certificate? In the general form, it is the public key of that user, the public key of A, including the identity of the user saying, this public key belongs to this user, a time stamp, this public key belongs to this user and it's valid for this period of time. So maybe two time stamps. This public key is valid from today and it will expire in one year's time. And importantly, it's signed by the authority, the signature of the authority. We encrypt with the private key of the authority. That's the certificate of A and similar, the certificate of B is the public key of B signed by the authority. We'll write them down. I'll try and remember the same notation. The time stamp, T1, the identity of A, the public key of A, signed with the private key of the authority is the certificate of A and similar for B. Different time stamp, it's issued at a different time. I can squeeze it in the ID of B and the public key of B. This information is known by the users after the initial manual exchange. It's similar to what's on the slide. Any questions so far? Welcome to those that came late, missed the first half. So now the automatic exchange. When two users want to communicate, they don't have to contact the authority. They communicate directly by sending each other their certificate. A sends a message to B containing its own certificate and B responds. So that's the steps in this case. And I try to highlight in this diagram, whenever any two users want to communicate, there's only two messages exchanged and those messages don't involve the authority. And compared to using a public key authority, that's where the benefit is here. When we have many users, there's very little load on the authority. It's just directly between the users, so the performance is not such a problem. Does it provide the same security as the public key authority? Well, how do we use the certificate? When B receives the certificate of A, the certificate of A is signed by the authority. When you receive a certificate that is signed by someone, you verify. So when B receives the certificate of A, it verifies using the public key of the authority. And there should be a space down here, but B knows the public key of the authority. We obtain that in the manual exchange. So when B receives the certificate of A, it verifies using the public key of the authority that that certificate has not been modified. It's valid. It was signed with the private key of the authority. It should successfully decrypt with the public key of the authority. Once we verify, we now know the public key of A. And similar when we send back CB, CB was signed by the authority. It contains B's public key. When A receives that certificate, A verifies using the public key of the authority and finds the correct public key of B. So the steps here, we verify as we receive a certificate. B verifies CA. And when B sends back CB, when A receives CB, it also verifies. Whenever we receive a certificate, we should verify to check that it's valid. Questions on using a certificate authority so far. The difference between public key authority and certificate authority, make sure you're clear on that. And why a certificate authority provides the same security. Remember the aim is to get each other's public key. And that aim is achieved after these two steps. B receives the public key of A. And they know it's A's public key because it was signed by the authority. And we trust the authority. We already have its public key. Similar, A receives the certificate of B. The certificate of B contains the public key of B. And A trusts that received certificate because it trusts the authority. And hence we have achieved our aim. Okay, that doesn't mean it's okay that you can see the picture. Any questions? So the certificate authority provides better performance than the public key authority. Not better security, better performance. There are no exchanges with the authority. T is a timestamp. We'll see some specific examples shortly. But it may be this public key is valid for this period. In fact, it may not be just one value. But it's something to indicate when this certificate expires. Like I issue you a certificate signing that it's your public key. But I only issue it valid for one year. If you want to have a certificate for longer, you need to get it reissued or a new one issued. We'll see that's how it's used. ID is something that identifies that user in the system. It depends on where we use certificates. It could be some address of the computer. It could be some identifier of the user in the system. We'll see when it comes to websites, the ID is a domain name. www.facebook.com is the ID used for the Facebook web server. And public key, what is the public key? Well, that may be an RSA public key or other algorithm. Certificate authority is because of this performance advantage across a public key authority are widely used today. And the primary means for secure communications in the worldwide web. HTTPS makes use of digital certificates and other security systems. So what is a certificate? Well, in general, it's the public key of a user and its ID. A timestamp usually indicating a period that this certificate is valid for or an expiration date. We'll see in practice it's usually a start date and an expiration date, two dates, two timestamps. That's the general approach. In practice, there are specific formats. So when we use software to exchange certificates, our computers need to agree upon a format. And the widely used format is referred to as X509. So there's a standard that says certificates should be structured in this way. And they're used in many different network applications, especially in web security. So I'll show you some examples of real certificates and we'll see the format. But remember that key information, public key, identity, some timestamp, and signed by an authority. In practice, when we sign something, what do we do before we encrypt? Before we encrypt to sign something, what do we do with a message? When we sign a message in this diagram, or this slide I say, we encrypt using the private key of the authority, our message. In practice, we don't encrypt immediately, we do something first. What do we do first? We want to make it maybe smaller, the message. Take a message, we don't just encrypt it, we do something with it first. Any ideas? We started it in the topic on authentication or the topic before this. What was the topic before? The topic, look in your lecture slides. We calculate a hash. If we calculate a hash of the message, we get a short value. And then encrypt that short hash value. So even though in these examples we write, we sign by encrypting using private key of the message. In practice, and we'll see when we look at some examples, we take a message, we calculate the hash of that message, and we get a short hash value, short relative to the message, and then simply encrypt the hash value with the private key. So real signature in practice is an encrypted hash value. But it's the same security as encrypting the entire message, it's just more practical to encrypt the hash value. So we'll talk about X509 certificates, the format, and then I'll show you some examples and see how they're used. X509 is the name or the number given to the standard, widely used in HTTPS and other systems. The format is what's included inside the certificate. What's the format of the ID, of the public key and so on. And the fields, the main fields are listed here. The standard has gone through different versions. So inside the certificate we indicate what version we're using. There's a serial number issued to the issuer. The issuer is who signs it, the authority in this case. So they have a serial number. What algorithm are we used for signing? Signing involves a hash algorithm and a public key encryption algorithm. Which ones are used need to be specified. The issuer is the entity that signs. The subject is the entity who has their public key stored in the certificate. So someone issues a certificate to some subject. So inside the certificate is some name and identifier of the issuer. The subject's name and identifier. There's two timestamps normally to indicate when this certificate is valid form and to, when it expires and when it starts. And the public key information is included. So what algorithm is the public key encryption using? Any parameters for that algorithm and the actual public key? So the key is the important thing in the certificate. And then the signature. And the signature is the hash of all the data encrypted with a private key. So we'll see through examples what they look like. So when you access a website, for example, we, on the course website, are we using HTTPS? No, we're not. But when we log in, if you know the padlock, the padlock up the topic, my browser, and we know that it says HTTPS here. HTTPS, and we'll see it in the next topic, which is a last for this course, we'll see that that uses certificates to provide some level of encryption. So we just want to look at the certificates for now. Because we would like to communicate between my browser and the web server. And to do that communication securely, we need to encrypt, and we need to exchange a key, and we use public key crypto to do that. So let's look at the certificate. If we click on here, we see some more information. We have a secure connection, and let's get some more information. And we find and we can view the certificate. And we'll look at some of the details. But in summary, there's a certificate here. We'll look at the details. The certificate was issued by one organization and issued to some subject, issued to and issued by. Who is the subject in this case? Can anyone see? What's the idea of the subject? Those at the back may want to come closer, it's hard to see. So you come up closer. You can come up here and you join him. Then you can see much clearer. Who is the subject in this example? What is the idea of the subject? Anyone want to guess? A guess? S-I-T is a subject more precise in this case. Star.s-I-T.tu.ac-t-h. Issued to, this certificate is issued by someone to the subject. So the subject is S-I-T, but more precisely, the identity is not S-I-T. The identity is a domain name. We'll hear a special case, not a full domain name, but it uses a wildcard. Meaning this certificate applies to any domain name that ends with S-I-T.tu.ac-t-h. I-C-T, I-T, reg, www, and so on. The same certificate is used for a number of different domain names. That's called the common name. In the standard, that field is the common name. The identity of the subject. The identity of the authority that issued the certificate is listed here, this Komodo RSA domain validation secure server CA. So there's the identity of the authority. So in short, Komodo RSA issued a certificate for the S-I-T domain. That certificate begins on the 25th of March. This year, and it expires in August, sorry, July next year. So this is like the time stamp. But in fact, there are two time stamps, the start and end time. And in web browsing, your browser will check the validity of this certificate. When it receives the certificate, it would check if the current date is within the period of validity. And if it's not, for example, if today's date was in past the expiry date, then your browser would at least present a warning or maybe a security error saying you've received a certificate which is invalid. And remember, a certificate is the public key of the subject. It's the public key for S-I-T signed by the authority. And there's a fingerprint, which is the hash values of this that allow us to quickly verify that. So to see the details, we'll zoom in, see the other fields in here. And we'll see, in fact, there are three certificates shown in my browser here. There's a hierarchy. But we'll come back to those other two first. We'll first look at the certificate that belongs to star.sit.tuacth. And this certificate contains a number of fields. We see it starts with the version. The standard has gone through different versions. This is version three of the standard. It has a serial number. So this certificate has this number issued to it, so like a random value for each certificate. The algorithm used for the certificate, for the signature. Remember the signature? We take a hash of the message encrypt with a public key algorithm. The hash algorithm used was char256. The public key algorithm used was RSA. The certificates support other algorithms, so you don't have to use this pair. This is common in this case, but you can have different hash algorithms and different public key encryption algorithms. Who issued the certificate? Komodo RSA, Domain Validation Secure Server CA. You'll see that Komodo is a company that won rollers to issue certificates. And you'll see that they have a number of different certificates we'll see shortly. The other fields are just some optional organization units and location address fields. So the common name CN there is like the ID when we write in our shorthand. Time stamps, not valid before this date and time, not valid after this date and time. The subject, who is it issued to? And here we have a common name. The ID is a domain name which ends with the SIT domain. So it covers a range of domain names. Sometimes we would see a specific domain name. Sometimes we see a wildcard, this star value. So in web security, the common name or the ID is always a domain name. And the actual public key, that's the important thing in the certificate, what is the public key? Well what algorithm is used for the public key, RSA? What is the public key? Remember when you generated your public key, you generate in RSA E and N as the public key. N is the modulus, E is the public value. Those values are given here. The modulus of those bits and I can't scroll down very easily. Down the bottom, E, the exponent, this common value of 65,537. So when SIT generated their key pair, they generated this value of N and E. That was their public key. They submitted this public key to the authority, Komodo, the company. And the company Komodo issued this certificate to SIT. That's the main information so far. The certificate contains some extra extension information which is, we haven't drawn in our examples, some identifiers. You can have certificates revoked. A certificate is issued, it's valid from this date to this date, but maybe something goes wrong and a key is revealed so we need to revoke a certificate. So there are methods for checking whether the certificate is revoked or not. Certificate revocation lists, but that's extra information. The last thing, again, the signature is the hash of all the other fields encrypted using a RSA key. The signature is given here. So these bits, or the hex vote is here, if we take all the other fields, calculate a hash using SHA-256 of all those other fields and then encrypt with a private key, we get these bits, the signature. Which private key? Which private key was used to get this signature value? Whose private key was used to get that signature? The signature is the hash, encrypted hash. The private key of the authority, in this case, Komodo RSA domain validation, that company, that specific key of that organization. So the private key of the authority was used to encrypt the hash of all the other fields and the result is these bits here. That is the signature. This is the certificate of SIT. Let's just note it down and we'll show you some other values. We'll see that there are multiple certificates. And rather than writing down all the values, I'll write a summary. There are many fields there. I will not write them all down, but the ID of SIT was in there. The public key of SIT, there was a timestamp when it was valid from and to. I'll just denote as T1. And then there were some other fields which were not list, like the version, the algorithm used. And then at the end, we attached the signature which is we encrypt using the private key. Whose private key? The authority's private key. In this case, the private key was that of Komodo. Komodo. And I'll just go back. The actual name, which we're not right. Komodo RSA domain validation, secure server CA. I'll write Komodo D, because we'll see there's another one in a moment. Komodo D and the hash of what? We take the ID of SIT, the public key, the timestamps, all those other fields. And all of those fields are used in the hash algorithm. Then that hash value is encrypted with the private key of Komodo, the domain validation server. And that becomes that certificate of SIT. Some of those values, the ID we saw was actually star dot SIT, a domain name or a range. The public key, we're not right the value, but was a 2048 bit RSA key. The timestamp was actually two timestamps, from and to time. So this was a certificate issued to SIT. When I accessed the ICT web server to log in, my browser contacted the ICT web server, and the web server sent me this certificate. What did my browser do next? Verify, I verified the certificate. Whenever someone sends you a certificate, you verify it. We check. Is it valid? We check the timestamps. Is it within the period of validity? But more importantly, how do we verify? Use the public key of the authority, in this case, who? Komodo domain validation server. So we need to verify using the public key of the issuer of the authority. So, how did my browser have the public key of Komodo? Maybe it was manually exchanged outside. So, automatic exchange was the certificate of SIT to learn the public key of SIT, but that was issued by an authority, and we've said so far that, well, we must manually exchange to get the authority's public key. It may not have to be manually exchanged. There's a word. You can securely connect to SIT and get this certificate. Check and you'll see it on your phone. Don't worry about your scores for other courses. They won't help you in this course. So, to verify this, my browser needs the public key of Komodo. Where do I store public keys now? In fact, a certificate is just a verified public key. A certificate contains the public key issued by someone else. So, if we go back to my browser, this was the certificate for SIT. My browser also has the certificate for Komodo domain validation. So, I have a second certificate in my browser. The subject of that second certificate is Komodo RSA domain validation secure server, the issue of mine, and the issue of the second certificate is another identity. Same company, slightly different name. Komodo RSA certification authority. We actually have a hierarchy. Okay, we may not just have one authority, we may have multiple authorities. And we see that in this example. So, let's write down that second certificate. Not in full, but we'll see that there's also a certificate of Komodo domain validation, Komodo D, which contain the ID. And so on, I'll not write them all down. The public key, the public key of Komodo, encrypted with the private key and the hash of all of that. Whose private key was used to encrypt Komodo's certificate? It's a bit confusing because Komodo issued it as well. The subject I'm calling Komodo D, Komodo domain validation secure server, the issuer is Komodo certificate authority. So, let's call that Komodo CA, just to be distinguished between them. Note the slightly different names here. Komodo D, and this one's different, the private key Komodo CA. Both of those certificates are stored by my browser. How do I know that that second certificate, the Komodo D, is trustworthy? Do you trust the second one? When we say trust, we mean it must be able to verify it. If the second certificate was encrypted with the private key of Komodo CA, to verify we need the public key of Komodo CA. The certificate of SIT was issued by Komodo D. To verify that, I need the public key of Komodo D. I have the public key of Komodo D in the certificate of Komodo D. To verify that one, I need the public key of Komodo CA. I have the public key of Komodo CA in a third certificate. Here's the third certificate. It's the certificate of Komodo CA. The subject is Komodo CA. Who is the issuer? Who is the issuer? Let's write it down and see. I know it's hard to see. Let's write down what we have so far. Who issued this third certificate? Which Komodo? We've got two different subunits, really. Let's have a look. The subject is Komodo RSA Certification Authority, Komodo CA, who issued this, the same organization. That is, they issued it to themself. This is called a self-signed certificate. This is a certificate of Komodo CA. The public key of Komodo CA signed by Komodo CA. They signed it themself. Let's write it down. So the private key was used to sign this was that also of Komodo CA. It's the C, and we've reached the top level of the hierarchy because to verify this certificate, we need the public key of Komodo CA. Well, the certificate contains the public key of Komodo CA. That's why we say it's a self-signed certificate. The problem is, do we trust it? Why do we trust it? What does trust mean with certificates? Trust means we can verify with a public key. But at some point, we must stop at the top level. At some point, we must implicitly trust someone. And that's what we have here. This is called a RUD, a RUD level authority. We trust Komodo CA. That is, we have their self-signed certificate. We trust it is the correct one. Now, since we trust this certificate, we have the public key of Komodo CA. We can verify the next certificate. The next certificate of Komodo D is signed by Komodo CA. We trust Komodo CA. We have the public key of Komodo CA. So now we trust Komodo D because we've verified that their certificate is correct. If we trust Komodo D, we can verify SIT's certificate because SIT's certificate is signed by Komodo D. So we see some chain of trust here. SIT has a certificate issued by Komodo D. Komodo D has a certificate issued by Komodo CA and Komodo CA has a self-signed certificate that we implicitly trust. We must trust that. If we keep going in the hierarchy, at some point there must be a route of that hierarchy what we must trust. That's called a RUD authority. So those chains can be quite long. It's not just two levels. Any questions on the role of certificate so far? Very important because used every day for web security. And other application security. Okay, all right. Yeah, good. Let's go back to our browser. We can summarize that chain of trust. Some notation we'll commonly see is this. Actually, we'll make it easier to write. The chain of trust, we can summarize like this. SIT, we'll see on the slides this notation is used. The certificate of SIT was issued by Komodo D. And the certificate of Komodo D, just some shorthand notation to show the certificate, was issued by Komodo CA. And the certificate of Komodo CA was self-signed. Implicitly, my browser trusts the self-signed certificate. If I trust this certificate, then I can verify the next one in the hierarchy. And therefore trust the second one. And if I trust Komodo D, I can verify SIT and trust SIT. So we build a chain of trust. So the question, a good question, why do we have multiple levels here? Why not just have a certificate of SIT and Komodo CA? First, where does the certificate of, why do I trust Komodo CA? I trusted SIT because I trusted Komodo D. I trusted Komodo D because I trusted Komodo CA, but why do I trust them? I need to trust someone, okay? With respect to my browser, why does it trust them? When I downloaded, installed my browser, Mozilla, the company that made it, had done some checks on this company, Komodo CA, and they trust them, and therefore they've preloaded this certificate into my browser. We can see that in the browser, as part of the install, it comes with the certificate. So we must trust someone, and in this case we trust Komodo CA. So the question is, why can't we just have Komodo CA issue SIT certificate? Well, because this process of issuing a certificate takes some manual steps. SIT, as an organization, goes to an authority and says, will you issue me a certificate? And the authority should say, prove that you are SIT, and you own that domain, and maybe go through some steps to offer that proof, and that's manual, and that usually costs some money, or there are some, maybe you have to pay to get that issuing of the certificate. So that takes time. So there are many organizations that do that. So rather than Komodo CA to issue certificates for every low level organization, it delegates the responsibility to subunits. And the difference may be the level of trust, or the level of proof that's provided to get the certificate. If you want a certificate, just as a normal user, maybe you can show an email address or put something on a website to show that you own the domain, and an authority will issue a certificate for you. But if a company wants a certificate for many websites, like REG, ICT, WWW, they need to go through more steps to prove that they are SIT, and there may be different authorities to provide that proof. Right, so we said, my browser trust Komodo CA, if my browser did not trust Komodo CA, then my browser would not trust Komodo D, and therefore it would not trust SIT. Let's see where our browser shows us that. If we go into the, your browser will show the certificates that you already trust. If we go into the advanced properties, what we see in the set up in the preferences of my browser, I have a list of certificates that I already trust. Let's go through, see if you recognize any of the organizations. Let's go across and scroll down, find Komodo. Here in my browser settings, I see that Komodo RSA certification authority is built into my browser. Here's a self-signed certificate. We saw it. With respect to my browser, it says it's a built-in object. When I installed my browser, it came with it, this certificate. You'll see some of them are called software objects. They usually downloaded after I accessed some website. So my browser initially, when I installed it, trusted Komodo RSA certification authority. After some time, my browser also trusted, where was the one? Was it this one? Komodo RSA domain validation secure server. That was downloaded and the chain of trust existed.