 So we got to this approach of using a public key authority, but before we come back to this authority approach and look at the another one, let's just make sure everyone understands the problem. I mean just going back to our man in the middle attack. This was a scheme we used to distribute a secret and that's what we're trying to do. A wants to communicate with B to do so. They want to encrypt their communications and using a symmetric key algorithm. So they want to encrypt everything using some secret key and in this scheme is denoted KS. So KS is their secret, but they don't know it yet. So they haven't communicated in the past. So this scheme uses public key cryptography to exchange that secret where A sends its public key to B saying, I am A, I want to communicate with you, let's create a shared secret. So that's step one. We send our public key to A, sorry, we send our public key to B, B generates a secret. It creates KS, let's say it generates a 256 bit random value and that will be the secret that they use for AES to encrypt the data. So B creates KS and is going to send KS back to A, but of course we cannot send the secret in the clear. It must be encrypted because if we send it in the clear across our network then someone can intercept and find our secret. So what B does is encrypts the secret KS using the public key of A so that if someone intercepts this message, message number two, they need the private key of A to try and decrypt and get KS. Without the private key of A they will not be able to learn KS. And who has the private key of A? A does. That's our understanding of public key cryptography. Only A has the private key of A. So the idea is that B sends this encrypted message back, A receives it, decrypts using the private key of A and learns KS. And from then on they use KS to encrypt their data, KS and some symmetric key cypher. So this is a common technique where we use a public key and public key encryption to encrypt a shared secret key. And once that secret key is shared we use that secret key to encrypt using a symmetric key algorithm because symmetric key algorithms are much faster than public key algorithms. But we saw that there's a problem with this. We went through and I don't have the picture here but we went through and you went through and tried to work out well what could an attacker do and come up with this man in the middle attack. A sends the message to B but someone in the middle modifies that message, in particular uses a different public key. Just to remind us of what it is. The man in the middle attack involved A sending a message as per the original scheme, public key of A and the ID of A. But the man in the middle that is C intercepting and modifying such that they send, so this is C receives that, you've drawn this before, they change the public key to theirs. They don't change the identity, B receives that. So C is somewhere in the middle of the path for the network, they receive the message before it gets to B and modify the public key. B thinks it got a message from A, B chooses KS and sends that KS back to A encrypted with the received public key. B thinks the public key of A is this value but it's in fact the public key of C. So B encrypts KS using the public key of C, not knowing that, thinking it's the public key of A. As a result, when C intercepts the reply, it can decrypt and learns KS. C can decrypt because C has the private key of C. And then C sends back that same KS to A but encrypted with A's public key, which is of course known. And when A receives this reply, they decrypt with their private key and they learn KS. So we've gone through this attack of this man in the middle attack, just to remind you that someone in the middle intercepts the messages and changes the public key. So this is not good. So what we're dealing with now is ways to make sure that the public key we have when B receives a public key, B needs to know this is A's public key. They need to be sure whose public key it is, otherwise such attacks are possible. So what we're dealing with is ways to prevent these attacks. And so to prevent a man in the middle attack on the public key, we need some secure way to distribute public keys. And we went through this scheme first. The way to securely distribute public keys is to get someone else to confirm they are indeed someone's public key. So in this case we introduced this new entity called the public key authority, who everyone trusts. So it assumes that this authority is trusted and that includes that everyone knows the public key of the authority. If you know the public key of the authority, when the authority sends you a value and signs that, so in message 2 this public key of B was signed by the authority, A can verify that because when something is signed with a private key, we verify that with a corresponding public key. So this scheme is really a way so that A and B can exchange public keys and they're sure they are the correct public keys. It's not a man in the middle attack like in the previous approach. And the way they do that is that the public key of B is signed by the authority and the public key of A in message 5 is signed by the authority as well. And since they are signed by the authority, both A and B can verify them by decrypting with the public key of the authority. And that comes back to our assumption that A trusts the authority, which really means A has the public key of the authority and knows for sure it is the public key of the authority. It's not someone pretending to be the authority. So we have that assumption. Maybe what happened is that A physically went to the authority, confirmed their identity and got the public key then. So this is just one scheme for distributing public keys so that if someone tries to send a public key pretending to be someone else we can detect that. It involves if A wants to talk to B, A sending a request to the authority and getting the public key of B, contacting B saying I want to communicate with you, B does the same to learn the public key of A. And the last two steps are just to confirm that these messages are recent and not being replayed by someone else. And the end result is A knows B's public key and B knows A's public key. Easy. One of the problems with this approach is that every time A wants to communicate with a new entity we go through these steps of contact the authority, get the key and the receiver contacts the authority, gets the key. Imagine there are thousands of entities in the network, they all need to communicate with each other. There's many contacts to the authority and it becomes overloaded, it becomes a bottleneck. Many packets are sent to the authority which must respond quickly. If the authority cannot respond then A and B cannot communicate. So the next scheme is one way to improve that, mainly from a performance perspective, not from security, and it's called public key certificates. So we'll go through the general approach, again the same objective, A and B want to learn each other's public key. And they need to be sure that they're their public key, not someone else's. So in the general approach we have some third party to confirm who's key it is. And in the previous scheme it was called a public key authority, here the more common name is a certificate authority. What happens is that A and B are issued certificates. To note it in this diagram is C A and C B. A certificate will contain the public key of that entity signed by the authority. And this is a bit confusing when we compare this diagram to the previous one. These four messages sent between A and the authority and B and the authority, there's no numbers on them. They actually happen before the communications need to take place. So they happen manually. Whereas in the previous scheme we didn't draw the ones that happen manually. All seven messages happen automatically across the network in this case. Contact the authority, give a response. Because if we want to draw the equivalent to what we have here, A and B want to communicate using certificates. Let's draw it. The scheme is quite simple. A sends its certificate to B in the first message and then B responds with its certificate. So if we want to compare those schemes of using the public key authority versus using the certificate authority, compare this diagram with this one. When we use the public key authority, every time A wants to communicate with someone we go through these seven steps. Contact the authority, get a response. Contact B who contacts the authority gets a response. The problem was that there was many communications to the authority. When we use certificates, it's this approach. A wants to communicate with B quite simply. A sends its certificate to B and B responds with its own certificate. And we get the same security as in the previous scheme. So we need to go through what is a certificate and what does it mean and why this is secure. Now this diagram compared to this one, it's actually these two steps. Step one and step two, that's all. It's just that this picture, it's a bit confusing, it includes the prior steps that must happen manually in advance whereas the public key authority didn't include them. So note when we use certificates, every time A wants to communicate with someone it's very easy. A sends its certificate to the destination and that destination let's say C sends back its certificate and then they're done. What's a certificate? In the same way that the public key authority signed A's public key, a certificate is A's public key signed by an authority. When we say signed by someone, we mean encrypted using that signer's private key. Confirming it came from that particular entity. So the certificate of A includes the public key of A signed by someone else, signed by the authority in our scheme. And in our diagram, back to the lecture notes, it's captured in these steps here. These two. So what happens at the start is user A goes to the authority and say I want a certificate. Here's my public key. And the authority confirms that this is user A and this is user A's public key. So in a simple example, let's say I'm the authority and all of the users are the students in this class. So one student comes to me and say here's my public key and I look at your public key, I look at your ID card to confirm this is you, it's not someone pretending to be you. And I confirm yes, this is you and this is your public key. Therefore what I do is I issue a certificate. That's what the authority does. They create a certificate which contains the public key of that user, PUA in this case, the identity of that user, some timestamp. So T1 here is a timestamp saying that this certificate is valid from right now maybe until six months in the future. And I sign that information. So the authority encrypts that information using their private key so that anyone else who has the public key of the authority can verify. So think of a certificate as the public key of a user signed by some authority. And we'll see that a different format, this is the general concept, we'll see a more specific format in a moment. Similar, B does the same. B goes to the authority saying here's my public key and the authority creates a certificate for them. C, B in this case. Now note that these steps happen in advance. That is whenever A wants to communicate with someone, all it does is sends its certificate. So once A has CA, its own certificate, if it wants to communicate with B, it sends CA to B. It doesn't have to contact the authority. If it wants to send, communicate with C, some other entity, it just sends its certificate to C. So it doesn't matter the destination, we don't have to contact the authority except in the very first instance. And that really cuts down on the communications because it's only that first step of being issued a certificate that we have to contact the authority. What is the certificate? What information is included inside? Here's one representation which is on the slide or on the diagram before where we said it includes the public key of A, the identity of A, some time stamp because instead of having certificates which are valid forever, we have some time limitation on them and importantly encrypted using the private key of the authority. And that allows someone to verify it if they have the public key of the authority. So again this comes back to trust. To be able to verify a certificate, you must have the public key of the authority and you must know it is indeed the public key of the authority. It can't be someone else. So we must trust the authority. The certificates, this is the general concept but we'll go through a more detailed view and look at some specific examples of how to store that information. That's what we'll do today. When we sign something, what do we do? When you sign, if you're using public key cryptography, when you sign something, how do you sign a message? How do you sign a message? Encrypt with something. Okay, you get an F in the exam if you say that. Anyone else? Encrypt with a private key, still not enough, F for you, maybe a D plus because it gets closer. Encrypt with more specific. If you want to sign something, what do you do? Hash is good. You'll get an A if you say hash but even if you just want a B, you encrypt with the private key of who? You. That is if you want to sign something, you encrypt with your private key. So make sure you're clear because remember everyone has their own private key. Think of all users have their pair of keys. So to sign something, you encrypt with your private key. Now more specifically, we encrypt a hash of the message using your private key. The hash is there for performance reasons, not for security. So let's write that down. Here we haven't shown the hash function but in practice we usually use a hash function even for certificates. So one way we can write CA, we have the identity of A. That is something that identifies this user in the system. We have the public key of A. So the actual public key of the user. We usually include some timestamp. So denoted here T1 meaning some information about when this certificate was created and how long it's valid for. And all of that information is combined with the signature. And we create the signature by encrypting using the private key of the authority, I'm going to run out of space. The hash, the hash of what? I'm running out of space, you'll find more space. The hash of all of this. So this is our message. This is the information we want to sign. Think of this as our message M. We take the message and combine it with the signature. This part is, if we M is here, this part is the signature. The message is the information we want to communicate to someone, our identity, our public key, some timing information, a timestamp. We take that message and it's signed. We actually take the hash of the message and encrypt the hash value using the private key of the signer, the authority in this case. So someone else signs this message on A's behalf. So message signature, where the signature is the hash of the message encrypted with a private key. That's the same as we've seen all through the content on public key cryptography. So really a certificate is the public key and identity and some other information signed by an authority, signed by someone else usually. When B receives this certificate, so in the first message, these values are sent from A to B. When B receives it, what does B do? B receives the certificate, what does it do? Decrypt. Decrypt what? The signature. The general process we say we verify. So to verify, we decrypt the signature, S, we decrypt it using which key? The public key of the authority. So if it was encrypted with the private key of the authority, we decrypt with the public key of the authority, we get a hash value, and we compare the hash value with the hash of the message, so this verification step. So we say the verification, verify, what do we do? We decrypt using the public key of the authority, the signature component, S here, and we take a hash of the message component, and then we compare them. So that's the verification step. Decrypt the signature, we should get a hash value, take a hash of the message, and compare those values if they're the same, everything's OK if not, don't trust it. So this is the same as we've seen with all of our signatures. To do so, we need the public key of the authority. So for B to do this verification, it must know the public key of the authority, and that's when we say we must trust the authority, including we must know the public key of the authority, and we must be sure it's the authorities, it's not someone else's. Because remember, that's our problem. Our problem is if you get a public key of someone, how do you be sure it's theirs? So we're saying that we have some initial trust that we are sure that the public key of the authority is indeed theirs. If we can do that, we verify the signature, meaning we now know the public key of A, and because we trusted the authority, we know that it is indeed the public key of A because if it wasn't, the verification would fail. B, of course, does the same thing. It sends back its certificate, and A verifies that. So same steps. Any questions? How does an entity become a trusted authority? So in a generic system, say then an entity must be trusted by the users. How does it become trusted by the users? Well, it depends on what system. Let's say the system is we want to allow all students to communicate. Then one way to get a trusted authority is to choose someone that you all trust, maybe me, and I become the trusted authority. Of course, that assumes that you all trust me. If you don't, then that system won't work. So in practice, in the internet, how does someone become a trusted authority? How do you trust me? Why do you trust me? Yeah, do you? Why do you trust anyone? Well, based on past experiences, if your past experiences with them have been positive, then you build up trust. So in practice, certificate authorities in the internet usually are based upon organizations that people have dealt with in the past and have done things that have built up their trust. But there's no absolute way to become a trusted authority. You must trust someone. Otherwise, there's no way to bootstrap to start this off. Any other questions so far? This is important because when you open up your computer and you open a website, in particular, a website using HTTPS to create a secure connection to that website, that web server is sending you its certificate. And we'll see some examples of that. So secure web communications uses digital certificates, and therefore it's important to understand what they are, what the limitations of them are, and how they provide security. Let's try our man-in-the-middle attack. See what conditions a man-in-the-middle attack would be successful. Yes, our assumption is that when we say we trust the authority, it means we know the public key of the authority. And our man-in-the-middle, let's call them M. Because we may use M for the message. Let's call them something else, D. I've got to choose a letter that we won't use. C, we use for a certificate authority sometimes. F, just so we don't get confused with some of the other letters we use. Remember our man-in-the-middle? A sends data to B, but F intercepts. The malicious user intercepts and makes some changes. So A sends its certificate to B, but F intercepts. What can F do? Well, can F learn A's public key? Yes, the public key is included in the certificate. So F knows the public key of A. F wants to forward on a message to B, making B think it came from A. What can F do? Let's try some different things that F can try. Let's say F tries to create a new certificate containing its own public key. I'll call it CA prime. It's not CA, it's going to be modified. And how is it modified? Let's say CA prime contains the public key of F, the identity of A, a timestamp, just to note T, and the signature component. And again, I will not try and draw the rest, but the signature component is the entire message hashed and signed. So we've got some missing parts here. We'll come to them in a moment. So the certificate, remember, public key, identity, timestamp, and then take all of those values inside here, hash them, and encrypt with a private key. Whose private key? Whose private key do we encrypt with? Whose can we not encrypt with? Normally, we'd encrypt, well, the signature is using the private key of the authority. But the malicious user F doesn't know the private key of the authority. So CA, maybe we can draw CA so people are clear. The original certificate, CA, public key of A, identity of A, timestamp, and then encrypted using the private key of the authority, the hash of all of those three values. That's the original certificate. Public key, ID, timestamp, hash it all, encrypt with the authority's private key. But when F tries to send a fake certificate to B, they've modified the public key of A to be the public key of F, hoping that B will receive this and use this instead of the public key of A. They don't change the ID, the timestamp. They copy from the previous one. They take a hash of all those values and encrypt with the private key. Well, the important point is that they cannot use the private key of the authority because they don't know it. It should be private just to the certificate authority. So let's denote, they use some private key X, the private key of X, hoping to fool B into thinking this is the public key of A. B receives the certificate and verifies. So try the verification steps. Remember the verify, we take the hash of the received message, decrypt the signature, try to verify. Do we have a volunteer to come and do it on the board? What is X? Good question. F received the certificate, CA. They want to change the public key, seed between CA and CA prime. The thing that's changed is, instead of PUA, PUF. This is trying to do a man-in-the-middle attack. So they change that. But they want to also change the signature. Remember, the message must come with a signature. So what they've attempted to do, they take the hash of these values and they encrypt using someone's private key. They should use the private key of the authority, but they don't know it. So I'm saying that they use some private key of X. It may be F's private key, but it's a private key which is not that of the authority. So it's a private key. B receives this, B verifies. And the verification steps are the same as always. We decrypt the signature component and compare to the hash of the message component. Remember, message component, signature component. Try the verification. This is the message component and this part here is the signature component. So the verification by B decrypt the signature component which was the hash value encrypted with the private key of X. And we're going to compare that to the hash of the message component. When B verifies, which key do they use to decrypt? No. The public key of the authority. B receives a message, a certificate. This certificate should have been signed by the authority. Therefore to verify it, you use the public key of the authority to verify. So you decrypt the signature component with the public key of the authority. And again, our basic assumption is that every entity knows the public key of the authority. And it is indeed the public key of the authority. What happens in the first step when we decrypt and then compare to the hash of this value? Why, what happens? Are they the same? So once we decrypt here and compare to the hash, we need to check, are they the same? No, they will not be the same, why not? That a different key was used between the encrypt and decrypt. Here we use the private key of x to encrypt some hash value. The hash value was in fact the same as this, but we decrypt that ciphertext using the wrong public key, using the different public key and the pair that was used to encrypt. Therefore the resulting output will not be the same as the original input. It will not be the hash value. So they will not be the same. And when we compare them and find they're not the same, then there's an error. That is, the certificate fails the verification. We don't trust it. So when B received this CA prime, as a result of the verification steps, it finds I don't trust the certificate. Maybe report the error or at least don't use the public key in future communications. So again, this is using same concepts that we've looked at when we look generally at signatures. Any other ways to attack? What can F do? What can F do to try and full B into thinking this is the public key of A but it indeed is the public key of F? What we did was we changed the public key and then we tried to regenerate a signature but we didn't have the right private key to generate the correct signature. So that was a failure here. Another way would be to change the public key but we just reused the signature from the previous approach, the previous, the real certificate. But again, you'd find out that the hash of this would not match the hash of the original value and therefore it would be detected. So changing just the message but not the signature would also be detected. So it turns out by using this signature then B can verify changes of the message and therefore because we have the public key of the authority at B, when we receive a certificate, we can be certain that we have the correct user's public key if it verifies. And B can do the same in the opposite direction. How did B get the public key of the authority? I know many people are thinking of that. Any suggestions? How does B get the public key of the authority? Could they use certificates? Yeah, so how does B get the public key of the authority? Because that's an important part here. That is, to verify, we use the public key of the authority because we assumed the signature was created using the private key of the authority. So what if we, if the malicious user, F created this signature using the private key of X and then F got B to think that the public key of the authority was actually the public key of X? So that would be a successful tack in that case. So we need to be sure then when we have the public key of the authority, it is indeed theirs. If we use certificates, we could do that, but it means that we need another authority to confirm that this is the public key of the authority. Remember all the certificate is doing is confirming this is the public key of a particular user. And it's doing so by having another user, the authority confirming that by giving it signature. So to be sure that it's the public key of the authority, we could include the public key of the authority in a certificate and have it signed by someone else, by another authority. But for that to work, we must know the public key of that other authority and we have this infinite loop. So we must trust one public key of one authority, at least. But we can have a hierarchy. It can be such that the public key of the authority is in fact signed by a higher up authority. And that makes things more convenient in large networks. It turns out in practice, usually public keys of authorities are stored in certificates as well. So we could say the certificate of the authority is the public key of the authority, their identity, a timestamp, T. Some indicator of how long this certificate is valid for. And then a signature. Again, we take a hash of those first three values in the signature. I just never have the space to draw them. So this could be the certificate of the authority, including its public key, its identity, the timestamp, the hash of all of those values and encrypted using the private key of who? Of another authority or itself? All right, let's do another authority first and we'll see the hierarchy. Let's say it was encrypted using the private key of someone else. I'll say authority to. You can see that. Someone else, some other authority. Meaning this public key is signed by a higher up authority. But then we have this same issue that the public key of this higher up authority, what is that? Well, it could be a certificate. The certificate of this second authority, we don't have to be limited by a single one, is its public key, its identity, a timestamp. We haven't said too much about that. We'll come back to it later. Encrypted using someone's private key of the hash of all those values. Same structure. Public key, identity, timestamp, signature. Where the signature is those values, hashed and encrypted with a private key. Who's private key? Who's private key? Hmm? Another authority, authority three. Okay? And you see where we get this continuation that someone needs to sign the public key. So we could have the private key of authority three. And then we'd need the certificate of authority three. Signed by authority four. And we'd go forever. Well, at some point in this hierarchy, we need a root. And the root authority has a special case certificate where it signs its own certificate. Let's say authority two is the root authority. It's signed by itself. Check the public key and the private key. Same entity. And we get what's called a self-signed certificate. So this is how the root authority distributes its public key. It creates its public key identity timestamp and signs it itself. Saying, I confirm that this public key is my public key. And that's what we need to trust. That is the other users need to trust this one so that they can confirm the lower level certificates. So if we trust this certificate, then we can confirm the certificate of the first authority which in turn can be used to confirm the certificate of user A and other users that it's signed. So we can have this hierarchy of certificates. And at the top of the hierarchy is a root CA and that has a certificate which we call is self-signed. The private key used there is the corresponding key of the public key inside the certificate. Self-signed certificate. It's like saying, this piece of paper contains my public key and I sign it to confirm it's my public key and I give it to you. How do you confirm that it is my public key or you cannot with a self-signed certificate? It's me confirming that it's mine. But anyone can do that. Anyone can say, here's my public key and I confirm it's my public key by signing it themselves. So there's no security measure in that. It's not secure a self-signed certificate because anyone can create a self-signed certificate. But in the digital certificate system we need to be able to trust at least one self-signed certificate. So how would we trust it? Then let's say it's an organization or an entity that everyone else trusts in that system and they implicitly trust that it is their correct public key. We'll look at the X509 certificates. Just some notation just to summarize this hierarchy. In this picture we use some notation saying that a certificate of X is issued by some authority Y by denoting it as shown here. So let's use that in our example. Some shorthand notation that says we had the certificate of A was signed or issued by our authority. And the certificate of the authority, not good names, but our first authority was signed by authority two. And the certificate of authority two was self-signed just a shortened way to write down who signs particular certificates. To verify one certificate we must trust the certificate of at least one other entity. So to verify a certificate we must trust or we must have the public key of the authority. And to verify that we must have the public key of authority two and we must in this case trust the self-signed certificate of authority two. So we can build up a chain of trust amongst these certificates. So long as we have the root in the hierarchy we can verify the others. Open up your web browser. People always sit in my classes with their laptops. Open your browser, do something useful and access the Moodle website. Log in, if you're already logged in, log out and log in again. And I'll do it here for those that don't have their computers. So my browser, I access the Moodle website and I need to log in. Well, here's somewhere the log in button. Log in. Now note the URL. Note in the top of the address bar there, the URL. ICT.SIT.TUACTH.Moodle. What protocol was used to access that website? HTTP. So accessing a web server, HTTP. Now I log in. And maybe you can see I cannot zoom. When you hover over a link, usually your browser shows you the destination URL down the bottom. Note that the destination is HTTPS. What's going to happen when I click on the link? Those with the computers click on the link. This connection is untrusted. If you didn't get that then you've been hacked. Okay? Then your login to Moodle is insecure. So this is a warning message presented by my browser. And let's see what it says. You have asked that, so this connection is untrusted. You've asked your browser to securely connect to ICT.SIT.TUACTH. But we cannot confirm that the connection is secure. Normally when you try to connect securely, sites will present trusted identification to prove that you're going to the right place. This site's identity, however, cannot be verified. So this is a message from my browser saying I cannot confirm, I cannot verify that this is in fact ICT server. And HTTPS, which is what we're using here, uses digital certificates for servers to verify their identity to browsers. When you access a website, you would like to know it is that website that you're setting up a secure connection with. It's not a man-in-the-middle attack. And this message is saying, well, we cannot be sure. Maybe someone between my browser and the ICT server is performing a man-in-the-middle attack. Because what's happened, and we'll see in details later, that the server has sent its certificate to my browser. And my browser has tried to verify the certificate but reports this error saying it cannot be verified. So this is an example of receiving a certificate that is not trustworthy. So let's not trust that and let's not go to that website. Let's try a different one. I open up a different website, again using HTTPS. Let's hope my internet works slowly. It's coming. Using HTTPS, and HTTPS uses digital certificates and it's connected to this website, no warning. Which implies that the server, this fsf.org, has sent their certificate to my browser. And my browser automatically goes through the verification process. It tries to compare the signature with the public key and identity information and if they're verified, it allows me to access the website. If it doesn't verify, then it presents that warning. And since it didn't present the warning, it was successful. Here I can see this little lock up the top, the padlock and if I click on that I can see more information. And it gives me a summary. The lock here. It says you are connected to fsf.org, the domain, verified by Gandhi SAS. So this is giving me a summary about the authority that has verified the identity of this website and more information. And your browser will show you, if you look into the details, the certificate of the web server. So here I'll view the certificate and it gives me a summary of the certificate sent by the server to my browser. Remember, a certificate is a public key and identity of some entity in the network issued by someone else, signed by an authority. So it summarizes, it's issued to fsf.org and it's issued by some other organization. The common name is just the field which indicates the domain for this certificate. Also includes optionally organization, organizational unit and some serial number for this certificate. So in practice we don't just include the public key and one field for the ID, we can include other values. Issued by is the identity of the authority, some organization called Gandy Standard SSLCA, CA Short for Certificate Authority and some organization name. And the time stamp, here it's stored as, represented by two values, the date when this certificate was issued and when it expires. So certificates have a fixed lifetime or a finite lifetime. Let's look at the details. And then my browser represents and shows that this certificate is actually part of a hierarchy. So the certificate for fsf.org was signed by an organization, Gandy Standard SSL and that certificate was signed by some other authority and UTN used a first hardware. It's just the shortened name for those authorities. So in fact here we have a hierarchy, one certificate signed by another which is then signed by a third. Similar to our example where we had a certificate signed by the authority which was signed by authority too. So there are in fact three certificates here. The web servers certificate, the first authorities and most authorities, or the root authorities. The details of those certificates are included here. And the format is referred to as X509. There's a standard that says what's the contents of a certificate? And the name of that standard is X.509. So it's commonly used in certificates. There have been some different versions. And we'll look through some of the fields in there. It's on the slide here. It shows the different fields, but we'll use the example to see them. We have something, identify the version of the certificate. It's a standard used. X509, I think, version 3. We'll see a serial number that identifies this certificate. So each certificate gets a different serial number. Remember we signed the certificate. Generally, we encrypt the hash value. What algorithms do we use for the hash value and for the encryption? So it gives some values here. The issuer is the authority who signed this certificate. Validity is like our timestamp. Not valid before this date, not valid after some date. And the subject is whose certificate it is. And we'll have the subject public key information. Version 3, that's just the version of the format for this certificate. Some unique serial number. So another certificate would have a different value. The algorithms used in this certificate. The authority who issued the certificate. So some values to identify that organization. It's usually an organization. It can be a person. Not valid before some time and date. Not valid after some time and date. So after that date, whoever receives this certificate should treat it as untrustworthy. So they should be updated over time. The subject and the important part is the common name. Which identifies in web browser, in web server certificates the domain. So here, anything.fsf.org. So this certificate is for that domain. When you visit a website with that domain, this certificate applies. The others are just, I think, the common name, the organizational unit, are just optional values. Then the public key information. The algorithm used, RSA, and the actual public key. Remember RSA. We have a public key which is E and N. And the private key D and N. So in the public key, N is the modulus. So there's the value 2048 bits in hexadecimal. And E is the exponent. 65,537. So this is the actual public key, the RSA public key, for that subject. For the web server. There's some extension, some extra optional information that can be used to support by the certificate authority. We'll not look at them. The algorithm used for signing. SHA1 with RSA. That refers to... We find it. The hash algorithm, H, is SHA1. And the encryption algorithm is RSA. So the signature algorithm refers to the two algorithms used here. We may use different algorithms. Sorry. And finally, the actual signature. So this is the 2048 bit signature used, which is that S part when we draw it on the screen. That's the certificate of the web server, FSF.org. It was issued by an organization called Gandy Standard SSLCA. To verify this certificate, we need the issuer's public key, which is stored in the next certificate up in the hierarchy. The subject is Gandy Standard SSLCA. The issuer, in this case, is UTN User First Hardware. So another authority. To verify this certificate, we need this UTN User First Hardware certificate. And we see that up in the topmost of the hierarchy, subject, and the issuer. Anyone want to guess? Who's the issuer of this certificate? Who? Itself. At the top of the hierarchy, we will have a root certificate, and it's a self-signed certificate. So the subject is UTN User First Hardware. The issuer is the same. UTN User First Hardware. So this is a self-signed certificate. It's the same as this example, where we had, think of this as the server's certificate, issued by one authority. That authority certificate was issued by a second authority, but that second authority certificate is self-signed by itself. It doesn't have to be two levels all the time. It can be a single level or it can be multiple. Let's go back to our first example just to finish. When I connected to ICT, what happened? It gave me a warning saying my browser could not verify the received certificate. Let's try again. Untrusted connection. Technical details saying the certificate is not trusted because it is self-signed. So the browser says, I've received a certificate from a server, but it's signed by the person whose public key is included. And if we want to access this website, we must manually trust the certificate. So I understand the risks and we can add an exception. We can actually view the certificate. In fact, since I run the ICT server, I've created a self-signed certificate because I haven't gone to the effort of creating a real certificate. And you can see it's out of date as well. 2012. So this is the issuer and the subject are the same in this case. So be careful when you access such sites. If we confirm the exception and we manually trust it, we can get access to this site. I'm sure you've seen others like that. Next week we'll discuss some of the issues. Well, why do we have that? Why is there a self-signed certificate? And other issues of where did the... Why did the browser trust these other authorities? So whose certificates do we initially trust? Some of the practical issues to finish off on certificates. And that'll be next week. Any questions on certificates so far? We'll see a few more examples next week. You'll see some in your homework, which is yet to be released, but will be today or tomorrow. Any questions? You've followed the certificates on your laptop? So the informal homework, when access some websites and check the certificates from your browser, just so you can get some examples and see the general structure to start to understand what's happening. A formal homework will be assigned soon.