 We know we can use public keys to encrypt a shared secret. For example, with public key encryption, what I can do is I can take your public key because it's public. It's easy to get. I take your public key and I choose a secret, let's say a random value, a secret key. I choose it and I encrypt that secret using your public key and then send it to you, the ciphertext, and only you can decrypt it. Because if it's encrypted with your public key, only you can decrypt it because only you have your private key. So that's a way to distribute a shared secret. We use public key cryptography to encrypt secrets. But the problem with that is how did I get your public key? How was your public key distributed from you to me in the first place? Well, it sounds easy because you just make your key public, but there are some problems and the main problem being is if you make your key public, how do I know it's actually your key and not someone pretending to distribute your key? So we got to that in the previous lecture. The ways to distribute public keys, the sort of the manual approach is to publicly announce them. I have a public key and I publish it on my website. I put an advert in the newspaper saying, this is Steve's public key. I attach it to the bottom of that email. And whoever gets that information has my public key. The problem with that is that when you get that public key, you're not sure if it really comes from me or if it's someone pretending to be me. So that's the problem we need to deal with. How can we prove that the public key that we get is of the correct person? And of course, we'd like to distribute public keys not by posting on websites or in newspapers, but distribute them across a network using protocols, so automatically between computers. So one approach is to have some form of directory, some special server where all the users, A and B, they publish their key in the directory and the directory is like a database listing all the keys of all the users. And when someone wants to find someone else's public key, they contact that directory or server. Again, still, how does the directory know that the public key coming from A is actually A's public key? It's not someone who intercepted that and modified it to be an imposter's public key. We arrived at an approach where we use a third party, an authority, to prove that or to provide some measure of evidence that a particular public key belongs to a particular user. So we'll just recap on this scheme in a moment. But the idea is that if I've got Steve's public key and if I give it to you, you want to be sure it's mine, it's not some student pretending to be me. And the way that you do that is you get some other person that you trust to sign my public key. If you trust some third party and they sign my public key saying, for sure, this is Steve's public key, and then I distribute that to you, then you can verify, ah, this public key from Steve is signed by someone I trust, therefore I will trust that this is Steve's public key. So the idea is to use some third party that we trust already to support this key distribution. And in this scheme, that third party is called a public key authority. When we say we trust the third party with public key distribution, it usually means that we have the public key of that third party already. So in this scheme, if I say the initiator A trusts the public key authority before any of this exchange of packets, then what I mean is that initiator A knows the public key of the authority. And they know that that's the correct public key. Somehow they got it and they are sure that it's the right key. For example, they went through some manual approach to contact the authority to show each other some identification and prove to each other that this is the correct public key. We said the problem of distributing public keys is when you receive one that you don't trust it, you don't know whose it is. But for this scheme to work, we must trust someone's public key and we trust the authorities in this case. So the goal of this scheme is if both A and B trust the authority, the goal is for A and B to exchange their public keys. So A learns the public key of B and they know for sure it is the public key of B. It's not someone pretending to be B. And similar, B learns the public key of A and B knows for sure that is the public key of A. That's the goal of this scheme. There are what, seven steps here. The approach is that the initiator sends a request to the authority saying, I want the public key of B. The authority sends back a reply, message 2, saying here is the public key of B and they sign it. When we say sign, it means encrypt with a private key. I sign a message with my private key. In this case, message 2 is signed using the public key authority's private key. Again, PR off is the private key of this entity. So that's the confirmation or the signing part which is then used by A when they receive message 2 because they trust the authority, which means that they have the public key of the authority. They can confirm and verify the signature. Anything they receive from the authority which is signed by the authority, they'll believe. That's the assumption in this scheme and that includes the public key of B. So now A learns the public key of B. Actually, we drew it last lecture. For those that weren't here, this is what we drew. The green ones here are what's known before this exchange of messages. So the assumptions in this scheme is that each user has their key pair. A knows the public key of A and the private key of A. That's normal. B knows its own key pair. In addition, A and B both know the public key of the authority. So that happens, that's known before this exchange of messages. That's that level of trust. If we know the public key of the authority, then we can verify anything signed by the authority. In addition, the authority has its own key pair plus the public keys of A and B. How do they get those public keys? Then we assume that maybe some manual exchange happened in the past. For example, user A went to the authority, physically went there and said, let's exchange our public keys and they use some way to verify each other. A has the public key of the authority, the authority has the public key of A and similar with B. That's the green keys. The request in message one, it's just summarized here's request, but what it would contain is the identity of A and the identity of B saying, I am A and I want the public key of B. That's what the request will contain. T1 is a timestamp, something that indicates that if this message is replayed, then the authority will be able to detect if it's replay and connect message two and one together by the timestamp. The authority receives the request, it knows the public key of B, it already has it, so it signs the public key of B as well as the request and sends it back to the initiator A. Now A has learnt the public key of B, so that's the first step of the key distribution. So after receiving message two, A learns the public key of B and it's sure it's the public key of B because it was signed by the authority and it trusts the authority. Message three is sending an encrypted message saying I am A and a nonce value to B, encrypted with B's public key. If it's encrypted with B's public key, only B can decrypt and that tells B that A wants to communicate with me. So B now needs to learn A's public key. So message four and five are similar to message one and two. B sends a request to the authority saying I want A's public key, the authority sends back A's public key signed by the authority and the respond to B verifies that because it has the public key of the authority. So after message five, B now knows the public key of the authority and in fact we've achieved our aim, both sides know each other's public key. The last two steps are to make sure that A and B are communicating with the right entity. So again the use of nonces to send a message back to A saying here's the nonce you sent me and here's a new one, encrypted with A's public key and a final confirmation from A. The idea of encrypting the nonces we've seen in other protocols, it's whoever can decrypt that message will learn the value and be able to give a response. So it acts as some proof that we're communicating with the right entity. So here's a way to distribute public keys. It relies on the authority knowing the public keys of all users first and the users knowing the public key of the authority. So some manual exchange of those keys. Once we have that we can use this protocol to automatically exchange public keys between A and B. If user C comes along then that go through the same steps between A and C for example. This works okay, one of the problems is that there's a lot of dependence upon the public key authority here, especially regarding performance. For every pair of users A and B that want to exchange public keys they need to contact the authority from both sides, get a response. If the authority is slow in terms of performance then the exchange of public keys can be slow. So the next approach we look at is trying to do the same thing as this, exchange public keys between A and B but trying to improve the performance by not having to always contact the authority. And it's referred to as public key certificates, we use an authority but here we'll refer to it as the certificate authority or the CA. What we do is instead of contacting the authority whenever we want someone else's public key, the authority issues a certificate to every user. The authority issues a certificate to A to B and those certificates are sufficient then to just exchange directly between A and B. We don't need to contact the authority each time we want to communicate with someone else. So this picture can be a bit confusing compared to the previous one. In this one every time A wants to communicate with B they go through these seven steps. With the certificate authority every time A wants to communicate with someone else B in this case they go through just two steps. See the ones labelled one and two? Those other four steps happen manually in advance. So don't be confused here even though it looks like there's six steps there's only two messages that need to be exchanged for A and B or two users to exchange their public key. The other four happen in advance. The result is that if two users want to communicate they just send each other their certificate and then they're done and we'll see how that works but that doesn't require any communication with the third party to exchange those certificates and therefore doesn't depend upon the performance of that third party and cuts down the messages in the network. So let's spend some time looking at what is a digital certificate? We'll look at it in the general form and then we'll give some specific examples with respect to web browsing. The first thing that happens before we contact anyone else is that we must contact the authority and say here is my public key. We say register the public key with the authority. That wasn't shown in the previous scheme. It also needed to happen in this scheme but it's just not shown on the picture. So before all of these seven steps somehow A must have sent a message to the authority saying here is public key A and the authority sent back a response saying here is my public key. It's just not shown in this picture. Similar it happens here. A sends a message to the authority saying here is my public key and the authority issues a certificate for user A. So this C subscript A here is C is short for a certificate. The certificate of user A. What a certificate is in the simplest form is the identity of a user, the public key of user, usually a time stamp to show how long this is valid for signed by the authority. So we see that in here. T1 is a time stamp, something like this certificate starts on today at 1pm and it finishes in one year's time. So some period of how long it's valid for. The identity of the user, as with all of these schemes we just denote IDA but the identity depends upon the system where this is used. For example it could be an email address for a user or a domain name for a website or some identity based upon some network address. So it depends on where the certificates are used as to what actual values used for the identity. But something that uniquely identifies that user and the public key of that user, public key of A in this case. And those three pieces of information are signed using the private key of the authority. That certificate is issued to A and A stores the certificate. Similar B does that. B sends its public key to the authority, the authority issues its certificate. The certificate of B and not shown here, A and B must also learn the public key of the authority. So let's write that and see what keys we know so far. Just to be clear that these steps are some form of registration. They only happen once and similar to the ones between B. They're usually manual. That is they may not happen across the network. So when you compare this diagram to the previous one, be careful that on the previous one we didn't show the registration steps. So it just happens once to issue the certificate. So what we assume at this before step messages one and two is that the authority has its public key and private key. It also knows, so after the registration process it knows the public key of A and B. So the green keys or information is what's known at the entities before the messages one and two. Of course A and B have their own key pair and we assume that A knows the public key of the authority. It could have been sent in this message as part of the registration in fact. So in practice some systems when you register with the authority, you register your public key, the authority will issue you your certificate, they'll also give you their public key. B also knows the public key of the authority and I'll also denote here, in fact it contains the public key of the authority but A has its certificate, C A and B has C B. So C A and C B are not just keys but the important thing in this certificate is the public key. If you look inside C A, it contains the identity, timestamp and the public key of A. So this is what information we have at the start and now A wants to communicate with B so they need to exchange public keys between the two users. All they do is they send each other their certificate. So steps one and two, A sends its certificate to B, B responds with its own. And when they receive a certificate, they can verify it because the certificate of A was encrypted or signed with the private key of the authority. When B receives that, how does it verify? How does B verify the public key, the certificate of A, the public key of the authority? So because it's signed with the private key of the authority, B can verify it with the public key of the authority. And once it verifies, it knows and has learned the public key of A. That is, from message one, it contains the public key of A signed by the private key of the authority. B verifies it with the public key of the authority and hence learns P U A. So it's learned the public key of A and similar when B sends its certificate back, it's signed with the private key of the authority and A will verify, it has the public key of the authority and learn the public key of B. And then we're done. We've achieved our aim of getting each other's public key. The key part of this, if we compare it to using the public key of authority, is that every time, so once a user has a certificate, every time they want to communicate with someone else, all they do is go through steps one and two. If A wants to talk to C, assuming C already has its certificate, A sends its certificate to C, C sends its certificate back. So just two messages exchanged and importantly, to communicate with C, they don't need to do another exchange via the authority. But with the public key authority, every time A wants to communicate with someone, they need to go through all these seven steps. They need to contact the authority, get the public key of the other entity, send message three and then the other entity gets the public key of A and so on. So this scheme, they achieve the same purpose but this one requires more messages and in particular, more messages via the authority. Using certificates, we just exchange certificates. The result is the same. We know each other's public key. So two different approaches to do the same thing. This one is better in terms of performance in that we don't have to rely on always communicating with that central third party, which is much more useful in large systems. Like in the internet, your browser wants to obtain the public key of a web server. So rather than getting your browser to contact some authority and then exchange messages with the authority, you use certificates. Your browser obtains the certificate of the web server directly from the web server. It doesn't have to contact any third server, third party entity in that case. So that's commonly used for secure web browsing, HTTBS. You need the public key of the server at least to allow secure connections in web browsing and the way that it works is that quite simply the server sends the certificate to the web browser. So we'll see some examples of that. So how often do we need to get registered the certificate and renew it? So in theory, we don't need to repeat. Once we do it once, then that's sufficient. That is, I've got a public key, I register with the authority, the authority issues a certificate. But in practice, the authority has to check that the public key actually belongs to A. So this step is usually manual. For example, you may have to submit, say for a web server, you may need to submit some documents that you own this website, that you own this business to some authority. You submit those documents, so they check the documents that this is your passport ID, your business registration and so on, and then they issue a certificate. So that's a manual and often time-consuming and resource-consuming process. And the authority takes some responsibility there that they have checked that information. So there's a timestamp associated, which means that, okay, this information maybe is valid for six months, 12 months, several years, but after that time, then you'd need to reissue the certificate. So in practice, for web-based systems where certificates are used, commonly certificates are issued for one year, they may be shorter, they may be longer. Whereas in this case, every time we want to exchange public keys, some cases we can use caching, but if not, then we need to do this every time we want to communicate with someone else. It could be every second, depending on how often we're communicating. If we use this approach for web browsing, for example, your web browser contacts the web server, every time your browser contacts a new web server, you need to go through these steps. Send a packet to some other special server, exchange public keys and so on. That's very inefficient when there's lots of communications. What else can we say about certificates? Let's see, what attacks can someone do? Anyone think of what can possibly go wrong? What can an attacker try to do in this case? Modify the certificates. That's the obvious thing. If we can do that, remember the goal is for each user, A and B, to learn each other's public key. If B gets a public key, and it thinks it's A's public key, but it's in fact someone else's, some malicious users, then that malicious user can do some attacks and intercept messages. If B gets the wrong public key, this system fails. What could an attacker try to do to make B get the wrong key, or could try to change the certificate? In fact, we'll draw it again. How can we change the certificate? Let's assume first that the certificates are already issued. So A has its own certificate, and B has its own. I'll not write it, but as always, each user knows their own key pair, their public and private key. In addition, we assume that A knows the public key of the authority, and B knows the public key of the authority. So the protocol is that once they have the certificate, they exchange a message. So A sends to B. What does it send? C A, which is in detail, encrypt with the private key of the authority, the timestamp, the identity of A, and the public key of A. So that is C A. Note that A doesn't do the encryption. That was done by the authority. The authority just gave it that information. So A just sends it as is as it received them from the authority. What can the attacker do? Maybe someone in the middle between A and B. Can they modify the message? Well, they could try. And I think we know from enough examples that if they try, what happens? If they intercept it and modified, if they modify P A, a public key of A to something else, maybe they change this to the public key of our malicious user, well, they need to re-encrypt it. If they try to modify the public key, they need to encrypt it. What can they encrypt it with? Or what can they not encrypt it with? They cannot encrypt it with the private key of the authority because they don't have that. And when B gets this message, it's going to verify using the public key of the authority. So if the attacker tries to modify something inside the certificate, B would detect that because B will always verify with the public key of the authority. So what else can the attacker try to do? Replay the certificate, send it again. What happens? So a replay attack is when we take a message from before and send it again. You would just look at, what if someone intercepts this message and sends it at a later stage? What does B do if it receives it again? B's receive this today and then tomorrow receives the same message again, not from A but from someone else, replayed. What does B do? It verifies, check the timestamp, well, in fact, in this case, the timestamp is a long duration timestamp. It's a period of, it's usually something like a year. It's not just the current time, it is the start time and the end time. It's different from the timestamps that we've seen before. It's just saying how long this certificate is valid for. If we replay this message, it's of no concern to B because this message contains the public key of A. So if B receives it again, so what? B has learned the public key of A again. And it is the correct public key, it's not some fake one. So if someone replays it, it has no effect for the attacker. They cannot take advantage of that in this case because the result is that B learns the public key of A. And it knows it is the public key of A because it's verified or assigned by the authority. So just be careful here. The timestamp is not there to prevent replay attacks. It's there to just to say that, okay, don't trust this public key after some date. And usually it's over a long duration, days, months, years. Whereas timestamps for protecting game replays, we're usually over short durations like milliseconds or seconds saying, okay, if it comes two seconds later, then that's a replay. What else can you do as an attacker? How can you be successful? Look at what's assumed. What does B assume it has at the start? The public key of the authority is assumed to be known by B. So we said that at the start B knows the public key of the authority. What if that wasn't true? What if it thought it had the public key of the authority, but it was in fact the public key of someone else? For example, it thinks it has the public key of the authority, but it's actually the public key of the malicious user. If that was the case, then what the malicious user does is that they intercept this message before it gets to B and now they can modify it. They can send on a new message to B. What can they do? They can encrypt using the private key of the malicious user, timestamp ID of A, and the public key of actually malicious user 2, let's say, sorry if it just fits in there. That is a different public key. The point is that B has a public key. It thinks it's that of the authority. So whenever it receives a certificate, it's going to use that to verify. The malicious user modifies the certificate of A to actually contain some fake public key, some of a public key that the malicious user knows, keeps the identity of A, saying this is the certificate of A, signs it. When B receives that signed message, it verifies and it passes the verification check because B has the wrong public key. So if the attacker can make B think the public key of the authority it has is the correct one, but it's in fact the public key of the malicious user, then the attacker can be successful when, say, a man in the middle attack and modifying the certificate as it goes between A and B. So that's why we assume that B and A both know the public key of the authority and they know for sure that's the correct one, because if they don't, this system fails. Yes, the result of this specific attack will be B will think it has the public key of A, but it's actually the public key of the malicious user. So later when B uses that to, say, encrypt some message, the malicious user can decrypt and that can be used in a man in the middle attack. It's all about getting the correct public key between A and B. So I see you all thinking about the question, how does B know for sure it has the public key of the authority? What's the answer? How do we know we've got the correct public key? We could get an authority to sign it for us. So when we get the public key of the authority, we actually obtain the certificate of the authority and I'll draw it again. So in practice what we do is when we had A and B, when we said that they already know their own certificate, and I said they know the public key of the authority, well usually that public key of the authority is stored as a certificate. I'll denote certificate of authority one. Where C A was signed using the private key of authority one, and so was C B. So the question is then how is B sure that this is the correct, contains the correct public key of the authority? This certificate could be signed by another authority. So the certificate of the authority is used to sign the certificate of A, and similar to sign the certificate of B. And to verify we have the correct certificate here, we could have a certificate of a second authority, which signs this one. And similar A. That is A certificate is signed by authority one. Authorities one certificate is signed by authority two. And if we trust authority two, then we can confirm that we have authority one's public key correct. And similar when we receive B's certificate, we can confirm the reception of the correct public key. How do we know that we have authority two's public key? We get authority three to sign it, okay, and so on. So we have this recursive problem of at some point, we're going to have to implicitly trust one of these certificates. We must, via some other means, be sure that it is the correct certificate. So we could keep going, but at some point, we have to say, okay, there's no one else that can sign this, because we need someone to sign there. So we may sometimes refer to this as the root certificate. A root certificate would be one that is implicitly trusted. Maybe we obtained it in a manual exchange via a very trustworthy source, right? So we can have a hierarchy of certificates and this chain of trust, but at some point there's the root in there that we implicitly trust. Who signs authority twos certificate? If that is the root, who signs it? So we say authority one signed a certificate, authority two assigned authority one certificate. Who signs authority two certificate? If there's no more authorities, it can sign it itself. So that's what commonly happens in practice is that it's a self signed, a self signed certificate in that, and we'll see the content shortly, but the certificate of authority two or the root authority contains the public key of that authority signed with the private key of that authority. They sign it themselves. There's no technical, is there a technical way to protect this? Right, you still need to have some trust point, some original trust in some entity. Now, trust is not binary in practice. Trust is not, if you think about the trust you have in people, it's not binary. I 100% trust you versus I 0% trust you. You build up trust over time, okay? And the same concepts can be used in network based systems where, okay, you trust something at a certain level. It's not 100% or zero, it's maybe 90% trust in that. So some systems extend this concept and the more people that sign a particular certificate and the more people of those that you already have communicated with, then the more trust you have in that certificate. So you can adapt it to build up the levels of trust, but still it relies on some implicit trust. Let's just write these certificates just to be clear when we say the self signed. So just in this example, another example doesn't have to be limited to just two levels, but just for brevity, we'll stick with two. So let's write down those certificates, CA and so on. So CA, we said, was encrypt with what key? Sign with what key? Private key authority one, some timestamp, the ID of A. And the public key of A. And the certificate of authority one, encrypt with what key? It's signed by the authority two, so that means it's encrypted with a private key of authority two. Some timestamp, I'll denote as T2, it may be different. The identity of authority one and the public key of authority one. And last, the certificate of authority two. Some other timestamp, the identity of authority two and the public key of authority two. Signed with what key? Self signed, so it's signed with its own private key. This is the special case. So this is the concept of those three certificates and the hierarchy we have between them or the chain. If user A, actually if user B receives certificate A, for example, they receive certificate A. So their goal now is to verify it. To verify it, they need the certificates of both authorities. Because what they do is they, when they receive the certificate of A, to verify they need the public key of authority one. Where is the public key of the authority one? Here it is. It's inside the certificate of authority one. So if B has the certificate of authority one, they have the public key of the authority one. But to be sure it's the correct public key, it's signed by the authority two. So if B has the certificate of authority two, the public key of the authority two, they can verify certificate of authority one, which then is used to verify the certificate of A. So B really needs all three certificates to complete that chain of verifications. And as you see at the top of that chain, we have the root certificate or a root authority. Right. If the timestamp T3 is out of date, okay, it expired yesterday, then what that should mean is that B no longer trusts the certificate and therefore no longer knows the public key of authority two. We can't be sure that the public key of the authority two is the correct one. Therefore we cannot verify the certificate of authority one. Therefore we don't, we cannot verify the public key of the authority one and we cannot verify certificate of A. So yes, we have to have each level and that trust in that chain trusted. If something's out of date, then you should not trust it and you cannot verify the other parts of the chain. Now to make things more confusing, certificates in practice are not stored like this. Can you remember digital signatures? What's a digital signature? We don't just encrypt with a private key. We usually encrypt the hash of the message with a private key and attach that to the message and that's what happens in practice. It's the same mechanism but in practice and we'll see in the examples coming up what we'll see a certificate looks like and I'll not draw it for all of them. The CA would be written as, let's see if we can fit it in. The message, those three values, concatenated with the signature. Remember in practice we said the signature is we encrypt with the same private key. So authority one's private key but we encrypt the hash of that message. So in practice that's how we'll see a certificate. So some web certificates will see it there of this structure. But the same concept applies. It's just a different way to store that information. It's much easier to deal with the hash of the values. So certificates are commonly used in internet-based communications for security, especially for web security. Sometimes other application security, some applications, non-web-based applications will use certificates to exchange public keys and some email-based applications. So we'll use web browsing as an example. So after the registration process then you just exchange certificates with the other user. So this is, we've seen this is the general concept, the public key, the identity and the timestamp signed with the private key of the authority. But in practice it can be the hash of that information signed. There are different formats. So we're talking about the concept here. Different standards specify exactly what is the structure of the identity, the timestamp and other information we may include here. So there are different formats. And the most commonly used format is referred as the X509 standard. So there's a standard that says certificates should have this information in them. The identity should be this format, the timestamps of these structures. And they're used in some forms of secure email, IP security in some networks, some electronic commerce applications use X509 certificates. And most commonly we see is in what's called the secure sockets layer, the transport layer security, which is used by HTTPS. The S in HTTP for secure really means use HTTP on top of SSL, secure sockets layer, which changed or which is upgraded to what's called transport layer security. In our next topic we will look at the details of these, but for now we'll just look at how certificates are used in web browsing. This sum of the information in a X509 certificate. It will contain the version, there's been different versions, some serial numbers, some identify the algorithm used for the signature. Remember the signature contains a hash value, a hash function and an encryption function. Here, H and E. What are those functions? What algorithms are used there must be specified. Is the hash function based upon SHA, MD5 or something else? Is the encryption function RSA or something else? So that must be specified. It doesn't have to be fixed. And the certificate will refer to the issuer. That's the person signing the certificate, like the authority. And they'll have some identifier, the timestamp, some start date and finish date. And the certificate of the user, the user is referred to as the subject. So there's the issuer and the subject. And importantly the subject's public key information, the algorithm used, the parameters and the actual key is included. So we'll look at some examples that use X509 now. So certificates are used in web browsing, but we'll see in the next topic how they use, in brief, they're only used to be sent from the server to the browser. So this web server, when you contact it, sends its certificate to you so you can use its public key to verify it's the correct web server. When you access a web server and you want to do it securely, then you want to make sure it's the correct web server. It's not someone pretending to be that web server. And one way to do that is to get the public key of that web server and if it's signed by some authority that you trust, then it can be used to establish a secure connection so that you know you are communicating with the correct web server. So certificates are only used in the one direction in web browsing, from server to client. The client doesn't normally send its certificate back to the server. So let's access a website using HTTBS. So HTTBS means use normal HTTP, but make use of the secure sockets layer that will do some encryption. But before it does encryption, it must exchange a secret key and we must verify the identity of the server and it will use a certificate to do that. So we'll access a website and not just because it's mine but because I know what the certificate looks like. And you see this padlock up here. You've seen it before, I'm sure, or different browsers may show a different icon, but something to saying we have some form of secure connection and if I hover over it says verified by someone, start com limited. Let's click on that and see some of that information and it says something about the website identity but here view certificate. So what happens is that when I access the website, the web server sends me, sends my browser, their certificate and when I get their certificate, I need to verify. Is this the correct one? Is this for the correct domain that I'm accessing? So let's look at the contents of the certificate. Start com in this case we'll see is the issuer or like the authority. So start com is the authority. This is the summary information. We'll look in the details in a moment. So this summarizes what's in the certificate. Issue two, that is who is the subject? Who is the user? So for web browsing, the identity of the server is given by the domain name. That's the most important thing here. So when we said IDA, IDB for web browsing, the ID is the domain name. So here's the domain name. The common name in the X509 standard. That's the important part in the certificate, the identity. So you can attach some optional information like organization, the department and some other contact information but in web certificates that's not necessary. What's necessary is the common name or the domain name. And that must match, the domain name in the certificate must match the domain name that you tried to access with your web browser. It is also given a serial number so some unique identifier when the certificate is issued. And issued by is the issuer or the authority. So this gives the common name of the authority. Here it's an actual name, a string, it's not a domain name. This is the organization or one part of the organization that issued the certificate to the website and some information. So StartCom is just a company that acts as a certificate authority. The timestamp, so it begins on this date, ends on this date. So it expires next month. And the fingerprints are just some summary information about that certificate. We'll see, first look at the detail. So let's see the actual contents of some of those fields. We'll come back to that. So let's look at the fields. There's a version of the X509 standard, a serial number for this certificate. The algorithm used. So the signature, it's signed using RSA, that's the encryption algorithm. And SHA256 is the hash algorithm. They may be different. This identifies the authority who issued the certificate. Remember, because we'll look at it in a moment, StartCom Class 1 primary intermediate server CA certificate authority from Israel. The timestamp, so the date and time when it's not valid before or not valid after. The subject is who it's issued to. And the most important thing there is the common name for web browsing. It should be the domain name. So this certificate does not work for mail.sandylands.info or abc.sandylands.info. It's just for www.sandylands.info. With, in fact, one exception. Sandylands.info on its own, it also works for. Most websites you can access with www. Or without the www. And web certificates are usually valid for both, but not for other sub-domains. You'd need a separate certificate if you want to have a different sub-domain access via HTTPS. Then the subject, so the user, their public key, remember, includes the public key. So what algorithm is used for the public key, RSA? What is their public key? Your experts at RSA, it contains the modulus N, 2048 bits. And if you scroll down, you'll find the public value, E as well there. So it contains the actual values of E and N for the RSA public key. Extensions are some optional information that gives some sometimes useful information, some IDs. Here's the part that it says that this certificate is valid actually for two different domains, with the www and without. The policies of the authority, so something to find more information about the authority, we'll not say much about, but if something goes wrong and a private key is compromised, then we shouldn't use that certificate anymore. So there are ways to revoke certificates before they expire. So this certificate expires at the end of next month. But if someone accesses the private key for this certificate, then effectively that public key should no longer be trusted. So there are ways to issue revocation requests to revoke a certificate. And the way that's kept track is that there are lists of certificates that should be revoked, meaning don't use some certificates. So the CRL is the certificate revocation list. The last thing, the signature algorithm, here's the signature. So this is the encrypted hash of all the other values. So that's included at the end. How does my web browser know to trust this certificate? So this certificate was received by my web browser from the web server. When we study SSL, we'll look at the packet capture and see the packet containing it. But at this stage, trust me, what happened is the web server sent this certificate to my web browser. How does my web browser know that this is a valid certificate? It's issued to the website, the domain name. It's issued by, and we'll go back to general. So this is the user. This is the authority. What do we need to verify this certificate? We need a trusted list. And inside that, what do we need? Or maybe another way. What key was used to encrypt the signature? The private key of who? The private key of the... What key is used to encrypt the signature? The private key of the authority. The issuer. So what we're seeing is an example of a certificate of a website instead of A. It's www.sandylands.info. It contains the information. It contains the public key of the website. And all of that is signed with the private key of the authority. Who is the authority? It's issued by StarCom Class 1 Primary Intermediate Server Certificate Authority. So we need the public key of StarCom CA to verify this certificate. Do we have it? How do we get it? To verify a certificate, you need the public key of the authority or, more generally, the certificate of the authority. So two different ways, mainly. I could contact the authority and say, give me your certificate. But then how do we trust that the certificate we get is the actual certificate of the authority, not someone pretending to be it? We saw we have maybe another authority that signs that. Remember, at some point, we must have some root authority that we implicitly trust. We must start from there. And in web browsing, the certificates of those root authorities are preloaded into your browser. When you download Firefox, it comes with a list of root certificates that the developer, Mozilla, trusts. And as a result, you also trust unless you change them. So let's look at them. So note that this was issued by the authority StarCom Class 1 Primary Intermediate Server CA. Okay, remember that. We'll close that. And let's now look for my browser by the preferences, by the advanced settings. We'll see a list of certificates. We can view the current ones. And there are several tabs here. The one authorities, this is the certificates that usually are preloaded into my browser. So I don't necessarily download them. I may have downloaded some, but some of these are built into the browser. We can remove them, and we can add others, but these are the default ones. So these are certificates of authorities. There's not just one authority in the world. There are many authorities. And the ones that are trusted by Firefox are listed here, and you may identify at least the country somewhere from Turkey, from Germany. Others, Komodo is a company that issues certificates. So there are maybe 100 plus certificates of authorities here. So let's see if there's StarCom here. Right. So StarCom has its certificates already loaded in my browser. And in particular, the one that was used to sign the website certificate was StarCom Class 1 Primary Intermediate Server CA. So let's look at that certificate. The subject, StarCom Class 1 Primary Intermediate Server CA. The issuer or the authority, StarCom Certification Authority. So here is one authority signing another authority certificate. Like we draw on the notes that A certificate was signed by authority 1, authority 1 certificate was signed by authority 2. Here authority 1 certificate is signed by authority 2. So to verify this, we need to have the certificate of authority 2. StarCom Certification Authority. And there are different ones here. You need to check the IDs to get the right one. Issued to StarCom Certification Authority. Issued by StarCom Certification Authority. What type of certificate is this? It's self-signed. If we look at the details, you'll see that this certificate is signed by the person whose certificate it is. They signed it themselves. This is the root authority in this chain. It's valid till 2036. So in this example, it was similar to what we drew that we had the website certificate signed by one authority, and their certificate was signed by another authority, which was the root authority in this chain. Any more questions before we give one final example for today? Yep. So can a malicious user establish an authority? Well, yes, anyone can create an authority. It may be in your homework task. I'll get you to create a certificate. It's not hard just using software to create an authority. But for it to be effective, if I set up my own authority, I need to get my self-signed root certificate loaded into the browser. So to be effective, to do an attack, if I am a malicious user, I start my own authority and will sign certificates, then I need to somehow convince Mozilla, who make Firefox, to either load my root certificate in this list, and they go through some rigorous checks to check the organisation that's doing it, or somehow I need to trick the user of the browser to import that certificate into there. So you can manually import certificates. If so, then you can perform attacks. So that's one weakness, a potential weakness in the use of certificates. You trust the browser developer, and you must trust those authorities. Do the different browser developers trust the same authorities? Not necessarily. I don't think so. Right. There will be cases where one browser will trust a website and another will not. And recently, I think Google removed one authority from their list. The Chinese Network Information Centre was compromised. Therefore, I think Google Chrome removed that authority from their list quite quickly. I don't know if Firefox has. So yes, the list may be different. It's up to the organisation to maintain that. But there will be some overlap. Last demo. Let's access your other favourite website. Not ICT. But we could, but this one's easier. It's even worse. Same with ICT, okay. Registration and we will log in. We've all seen this before. What happened? So the login web page uses HTTPS. So HTTPS is up here. And it says this connection is untrusted. We don't click I understand. We click the technical details. What are the technical details? It uses an invalid certificate. It's not trusted because it is self-signed. So it's signed by someone who's not in the list of authorities. It's actually signed by itself in this case. It's only valid for the domain 7. This should identify the actual domain, reg.sit and so on. And it expired four years ago. So there's three problems with this one. So you trust it, but you shouldn't because someone may be doing a man in the middle attack now. And there's no way for you to know whether it's someone doing an attack or not. But let's view the certificate and just see. So this is one that was issued. I think when someone set up the registration website and set it up, they just quickly created a certificate self-signed and issued to itself and hasn't been updated for several years. 7 is nobody, I think. I don't know why it's even 7. Maybe, 7 days. So the point here is that if a certificate is received from a web server and the chain of trust cannot be verified, then you'll get this error or warning. And if you say, I understand the risks let me through, then there's no way to confirm that an attack is not taking place. It can be an attack where someone's now intercepting your traffic. So the question is why not just remove the certificate? Well, the data is still encrypted, so it's still using HTTBS. So if it's not a man in the middle attack, it still provides some form of security in that the data is encrypted. But there's no way for us to know if someone is doing a man in the middle attack. So if we implicitly trust that no one inside SIT would do a man in the middle attack on anyone else, then maybe it's okay. Maybe later, after we look at SSL, we'll talk about how do you get a certificate and why would you have a self-signed certificate? There are some costs involved in getting certificates.