 So, the topic we're on is how do we distribute keys and we're up to the part of how do we distribute public keys. The challenge is that with public key cryptography we want to tell everyone else or the idea is to just to tell everyone else what your public key is. The problem with that is that when you, how do you inform someone of your public key and the person who receives it needs to be sure that it actually came from you and not from someone else. So when I post a public key on my website and you download and use that public key, how are you sure that it is in fact my public key and it's not someone else who has got access to the website and posted a public key. So how do we distribute public keys? Then what we said, there are different approaches and we said, okay, first approach just make some public announcement, post your key on a website in the bottom of your email, print it in a newspaper, whatever. But again the problem here is that we're not sure that this public key is for the person that they say it is. It could be someone pretending that it's Steve's public key where it's in fact someone else's. Another approach is that we have some directory, some computer, some server where the users of the system go to that directory and publish their public key. So each user goes to the directory and provides some ID, some physical ID, they go to the person who runs the directory, show some ID and say this is my public key, the person who runs the directory confirms. This person is in fact who they say they are and when you want some other users public key, A publishes its public key in the directory, B publishes its public key in the directory. When A wants B's public key then A contacts the directory and downloads B's public key. So that's the general approach of using some central server or directory to store. Of course if we store all the public keys here the directory must be secure. That is there must be no way for some user to get a public key in the directory which is someone else's public key. That is there's no way for me to go to the directory and say here is John's public key where it's in fact my public key. So we need some way to secure the directory and of course if someone gets access to that directory the system will fail. And two I guess specific instances of how do we do this across a network shown in this one and in the next example. So the concept is that we use some central server or some central trusted third party, some authority. In this scheme we have our set of users in this example just A and B and we have an authority, someone we trust that is the user's trust the public key authority. And so this is a case of a publicly available directory but it shows the protocol for exchanging the messages to get the keys of the other user. And before these steps are performed it assumes that each user has gone to the directory or the authority and published their key. So each user has done this step. User A has gone to the authority and said here's my public key and so has user B they've gone to the authority, the directory and said here's my public key. So they published their keys inside the directory or called here the authority. And also when you go to the directory you not only publish your key but you also obtain the public key of the directory of the authority. So before any of this happens the set of keys known and I think we covered this last week but quickly again the authority A and B the authority before these steps knows the public key of A, the public key of B. The authority also has its own key pair, public key of the authority and the private key of the authority. That's known by the authority before these steps. A of course has its own pair so does B, P-U-B, P-R, the private key of B, the other key pairs they are known by each user. And also A knows the public key of the authority so does B. They were obtained manually that is somehow user A went to the authority and gave them their public key and similar received the public key of the authority and they trust that. So we assume that they are trustworthy keys. We know that they in fact use the key of A and the key of the authority. And B has done the same. So that was some manual exchange. For example if I was running the authority and you were the users you would come to my office, you would show me your ID and I would check your ID and then we'd exchange our public keys. I would give you mine, you would have the authority's public key and you would give me your public key. And then these steps show what happens for A to communicate with B when we communicate across a network. So now there's some server and two users, two computers. A wants to communicate to B. To communicate to B, A needs B's public key. That's our goal here. A wants to find B's public key and similar because B will need to find A's public key. That's our goal of this protocol. So our initial state, the result should be that A knows P-U-B and B knows P-U-A. And when I say they know them, they must be verified. From now on in any of these messages an attacker could intercept a message and change it. So if we just send a public key from A to B, no encryption, no signature, if we just send the public key of A direct to B, there's nothing stopping a malicious user from intercepting and changing that. So we cannot rely on that. And that's why we have these set of six or seven steps. And the steps, the initiator A requests a public key from the authority. They request B's public key. So in this request, A is saying please send me B's public key. And the authority sends back a reply containing B's public key. Some information from the request including a time stamp so that A knows that this is a reply to their previously sent message. It's not a replay of some old message. So they can check if it's a replay from something that happened before. And importantly the public key of B is signed by the authority, encrypted using the authority's private key in this case. And A verifies that received public key by using the public key of the authority. Anything encrypted with the private key of the authority can be verified using the public key of the authority. And since we trust the public key of the authority, A trusts the public key of B. So now A has PUB. And step three, A sends a message encrypted using PUB so no one else can see it. Encrypted with a public key means that we provide confidentiality. Saying I am user A, B receives this message and B now knows, OK, A wants to communicate with me. I will need A's public key. So B requests from the authority the public key of A. The authority in step five sends back the public key of A again signed by the authority. When I say signed I mean encrypted with the private key of that user. Being signed by a user is encrypted using the private key. So step one and two and steps four and five are similar. It's just this is requesting B's public key and this is B requesting A's public key. And once B receives message five they verify the message using the public key of the authority. Once they verify everything's correct they now know A's public key. We've achieved our goal. Our goal was A and B know each other's public key after step five we've achieved that goal. Step six and seven are just some final authentication checks to make sure that message three was not a replay. So it's not about the distribution of the public key, it's just to confirm that someone didn't make this message up or replay this message from before. So it's just we saw this in one of the other schemes where we do some final checks and saying did you really send this? Yes I really sent this. So the idea in this scheme is that we have two steps. We say the manual exchange is the public keys between user and authority. That is before any of these exchanges each user goes to the authority and publishes their public key and similarly receives the public key of the authority. That happens before this. So if we have ten users each user must go to the authority and exchange their public keys. And once that's done when any user wants to communicate with any other user, A wants to communicate with B then they perform these steps, these seven steps. And as a result A gets B's public key and B gets A's public key. And if user C wants to communicate with D then they do the same set of steps. So the question is does the authority assign the public key? No, the user chooses their public key. So when you generate a key with public key cryptography you in fact generating a pair of keys. You create your own public and private key at the same time. You did that with Diffie-Hellman in fact, same with RSA and other schemes. You generate a pair of keys, a key pair. So user A generates its key pair PUA, PRA then manually goes to the authority and gives the authority PUA, only the public key. There's no need for the authority to know the private key of A, only the public key in this case. So the authority doesn't generate it, the user generates their own key pair. So first there's some manual exchange of public keys and then let's say across the network some automatic. When I say automatic I say I mean we can send these messages across the network across an open network, the seven steps shown on this diagram that's done via some protocol. So some software can do that and send it as messages across some network. Whereas the manual exchange we assume that there's some other channel for exchanging public keys like a physical exchange or some other secure channel. If there are 100 users then each user must exchange their public key manually with the authority and then when any pair of users want to communicate they go through these steps. This works, okay, it's secure, both users learn the public key of the other user. The problem is performance because whenever any user wants to communicate with another user they must perform these steps and each time there's a message to the authority from A and a response and similar from B to the authority. So now imagine we have a network with a thousand users, every time any pair of users want to communicate they both send a message to the authority. So many messages are going to the authority and the authority must respond with many messages. For every pair of communications there are four messages here. So we put a lot of load on the authority in this case. The authority becomes a performance bottleneck. If the authority crashes, it's a server for example, a computer running some software if it doesn't work it's unreachable and the system does not work because we rely on that authority then. If it comes slow because many messages are going to it then it'll be slow to respond and it slows down how A and B can exchange their public keys and hence communicate. So from a performance perspective this can be a problem, relying on that public key authority all the time. But from a security perspective it works okay. And when let's say today on the current day A communicates to B they perform these steps. Maybe tomorrow when they want to communicate with B again they may repeat the steps to check and get a new public key. But in fact you can improve the performance a little bit by performing some caching, storing some old messages in that case. But generally the problem is that the authority is a performance bottleneck. Everything goes via the authority every time any two users want to communicate. So an alternative is to use generally public key certificates. So we'll go through a scheme of how to use certificates and then start to describe the formal parts of what we mean by a certificate. So here's a different approach and we have these two users A and B want to communicate and an authority. Here we call it a certificate authority. We'll see that we use this concept that we call the things that we exchange as certificate and we'll describe what they mean but here's our central authority and the same as the public key authority but it has a slightly different role. Here we're showing the let's say the manual step of exchanging a public key with the authority. So don't be confused by comparing this diagram with the previous one. In this case we only showed the automatic steps. We didn't show the manual exchange. In fact the manual exchange is like this whereas in this diagram we're showing both. This is one of the, or this is the manual exchange. This happens before we do anything automatically across the network. And then so is this between A and the authority. The automatic steps are just one and two. Okay so if we compare to the previous case the manual steps we do something before we exchange across the network. These two messages and these two. The automatic just these two steps. So first thing we do is before we want to communicate with other users each user similar as before publishes a public key to the authority. Just the same as before we go to the authority and say here's my public key. So again A has its key pair, B has its own key pair and we'll see also the authority has a key pair. What do we call it here? Same as before each user has a key pair. They generate their own pair of public and private key. And then user A goes to the authority and says here's my public key. And the authority will check the identity. For example if I'm the authority you as the user will come to me and say here's my public key I'll check your ID and confirm this is actually you. So that's a manual step. So the authority learns the public key of user A and what the authority does is they issue a certificate to user A with the public key of user A and that's this second step here. This is a certificate or a simple form of a certificate for user A, CA. What a certificate contains importantly is the public key of a user signed by someone else where that someone else is the authority someone will trust. So we see that this in the shortened form is the public key of A we include the identity of A say the name of user A usually some time stamp saying that this is valid from this date onwards and it's signed by the authority encrypted using the private key of the authority. So this is issued to user A. So user A we say now has CA which is just its own public key but it's signed by the authority. That's the manual exchange. So each user is issued with a certificate from some authority and again as with before we trust the authority. B does the same. So the result is that the authority will have the public key of B and B will be issued with its own certificate and at the same time although it's not shown here A will learn the public key of the authority and so will B. So that's the knowledge from the manual exchange. So that's what we assume when the before we start sending packets across the network which is these two steps and these two steps that's part of the manual exchange. Similar to before A knows its own key pair as well as the authority's public key. The authority knows its own key pair as well as the other user's public key. So that's the same as we had before. In addition each user has their own certificate. What's our goal here? What are we trying to achieve from now on? What are we trying to do? Same as with the public key authority, what's our goal? It's nice that we've got some new students finally arrive at the end of the semester. So we'll ask them some questions later. What's the goal with this exchange? What are we trying to do? Identify. What are we trying to exchange? Public keys. What we're trying to do is A wants to know B's public key and B wants to know A's public key so that they can communicate using those keys. That's the same as what we were trying to do in this case. Just exchange each other's public key. In the previous case using the authority after the manual set up to exchange the public keys we performed these seven steps. Using a certificate authority we've done the manual steps to now to obtain a public key we perform just these two steps. All we do is we send each other our own certificate. A sends C A to B, B sends C B back to A and that's done across the network. So we send it in some message across the public internet for example. So the result after that exchange is that A knows C B and B knows C A. Remember the goal is for A to know P U B, the public key of B and for B to know the public key of A, that's the goal. Have we reached that goal yet? Have we reached the goal? We have the certificate. We want to know the public key. But what is the certificate? Just look at it here, just write it down. C B for example is encrypt using the private key of the authority, some time stamp, the current time, the identity of a user, ID B like the name of the user and the public key of B. That's C B as on the slide. A knows C B, first, can they decrypt this? Can A decrypt this? Hands up for yes, higher. Anyone else? Hands up for yes. Can A decrypt? Maybe this will be our quiz, our quiz that we need to have. We'll have a quiz today and we'll be made up of a set of questions, yes or no. Can A decrypt C B? Yes. Okay, enough people responded yes, what about no, anyone? Of course A can decrypt it because it's encrypted with the private key of the authority and A has the public key of the authority. In fact we say it's signed by the authority and we don't generally talk about encrypting and decrypting we say if it's signed by the authority we can verify it if we have the public key of the authority and we do have the public key of the authority and we trust that public key because that was obtained in the manual exchange at the start. Anything obtained in that manual exchange we trust because someone came to my office, they showed me the ID we trust each other and you obtained the public key of the authority. So first, user A can decrypt this or they can verify it and therefore they can see the contents, what are the contents, some timestamp, some identity, some name and importantly the public key of B. So when you have someone certificate you also have their public key. So in fact A does have the public key of B and importantly it is B's public key because it was signed by the authority and we trust anything signed by the authority because we trust the authority's public key. So A knows B's public key and similar B knows A's public key. So a certificate contains the public key as well as some other things and importantly that public key is verified or is signed by some other user, in this case the certificate authority. So we've achieved our goal, A and B know each other's public key and they are sure they are the correct user's public key because they were signed by the authority and we trust the authority. So in summary, in this approach there's these four steps in the manual exchange at the start. Every user must go to the authority and be issued a certificate if there are a thousand users that happens a thousand times and then whenever any two users want to communicate, A wants to send data to B then those two users just exchange their certificates and from a performance perspective that's much better than using the public key of authority. In the public key authority whenever any two users want to communicate they go to the authority, receive a response, exchange some messages and B also goes to the authority whereas with a certificate the authority is not involved it's just A to B when we do the automatic exchange across the network. So from a performance perspective in a large network this is much better. Same level of security, both cases the end goal of each user knowing the public key of the other user is achieved so the same level of security but better performance in this case especially in large networks and certificates, public key certificates the primary form for distributing public keys in the internet today. So when you access a website using HTTPS and I'll show some examples today you receive a certificate from that website which has been issued by some authority and your browser verifies the certificate that you received to check that you're contacting the website that you think you're contacting. So we'll see some examples of how your browser does that. So they're important in how we use public key cryptography in the internet. Once a user has a certificate issued to them they can just tell anyone what that certificate is just send it to them across an open network because importantly that certificate contains the public key of the user signed by the authority. So long as the other user trusts the authority then we can receive the public key. So when comparing certificates versus the public key authority same level of security different in terms of performance. So now let's look at the details of certificates. So the assumption is in general that the users have the public key of the authority. So then if you think about your web browser your web browser you're the user and the web browser is the user. If we receive a certificate from a web server we need to verify that certificate with the public key of an authority. So if there was one authority in the world then every user must have the certificate of that authority in your web browser. It turns out that doesn't scale very well just having one authority in the whole world and every web browser getting a certificate from there because the issuing of certificates also takes effort it turns out we have a hierarchy of authorities not just one authority but many authorities and we'll see the details of that. There's a few slides towards the end here and also in a demo with looking at our browser. So it turns out you don't need just one authority you can have multiple authorities for performance reasons. In this in this example scheme the certificate is shown as take the public key of the user some identity when I say ID the identity it depends upon the context or the scenario it could be a name of a user it could be an address of a computer but it's something that identifies that user in the system. See a timestamp usually in fact we'll see later we usually two times the time in which this certificate starts to be valid and when it finishes being valid. So this certificate is valid from today and to one year from today so in practice we'll see there's usually two times but in this example we say in general we need some timestamp to indicate how long the certificate is valid for. So the certificate was encrypted using a private key of the authority this is the general concept we need to have a public key signed by the authority how do we so this is a general concept of a certificate the specific format there are different options the most common format is defined in a standard called X509 and that's what's commonly used in the internet today so we'll look at the details of that format it's used in many internet protocols that are used for security today whenever you access a secure website using HTTBS there's a certificate involved so let's look at the content of these specific X509 format so an authority issues the user selects their own public key but the authority creates a certificate they issue a certificate and the certificates can be stored in some public directory they can be published on websites because when you receive a certificate you can confirm that it's valid by using the authorities public key what does the X509 format contain this information will see in detail the version of the format that we're using it's been improved over time we'll see that oh the algorithm used for signing that is here we say in encrypt using the private key of the authority what algorithm is used there and in fact we normally do not just encrypt using a public key algorithm we normally take the hash of the contents and encrypt just the hash of the contents so we'll see that in detail and we'll explain why some identity of the authority some time frame for which this certificate is valid for example it's valid from today until one month from now or one year from now and after that time frame you shouldn't trust the certificate the name or identity of the user the public key of the user and the signature so in fact in the general approaches we encrypt this information with the private key we'll see with X509 it's slightly more than that it's illustrated here in the diagram where we have Bob's certificate we have his ID something that identifies Bob his name some unique identifier Bob's public key so the value of his public key and some information about who the authority is the CA the name of the authority and we take that information and that will be part of the certificate that'll be included but we also take a hash of that so we use a hash algorithm MD5 char one some other hash algorithm and we take a hash of all that information and we get some hash value some fixed length small value and we encrypt the hash value using the private key of the authority so this is the signature phase in fact in practice we do not encrypt the entire content we just encrypt a hash of the content we take the content take a hash value encrypt using the private key of the authority of that hash value and as a result we get the signature and we attach that signature to the rest of the content and together the content plus the signature is the certificate and we can send that across a network publish that anywhere we like when we send it to someone they need to verify to check that it's valid what they do is that they take the signed part the signature part here and decrypt using a public key of the authority this part was created by taking a hash value and encrypting with the private key of the authority therefore we take that value and decrypt with the public key of the authority and we should get the hash value back and then we take the content and calculate a hash of the content and we compare these two values if they're the same we trust the certificate if they're different we don't trust it so we're using the concepts that we've seen in some of the other topics of taking a hash of the values signing and so on so this is the signing part we create a certificate by signing it this is the verification part we check if it's valid that's the general procedure let's look in some more detail of what is actually inside the x509 format what's the content it can't contains a set of fields our certificate the version of the protocol or the the standard we're using x509 has different versions some unique number given to this certificate so your certificate will have a serial number mine will have a different serial number so it can be just some long random number some details about the algorithm used for signing remember the signing there's two parts of the algorithm we take a hash and then we encrypt so we must specify what is the hash algorithm used and what is the encryption algorithm used and what parameters do we use for those so for example the signing algorithm could be use sha one as the hash function and use RSA as the encrypt function so what specific function do we use in those cases they are listed inside the certificate the name of the issuer this is the authority so the authority has some name some identity the two dates or times for when this certificate is valid so it's not valid before some time and it's not valid after some time so two time stamps or dates the name of the user the subject that's called formally so if it's my certificate my name would be here and in fact it's not just the name usually it's a they call a common name an organization name for example school of ICT SIT Thomas Art University so it can be more than just an individual person's name so the name of the user the subject the public key of the user or subject so what is your public key the algorithm used for the public key any parameters and the actual key is included here so if we use RSA the key would include would contain what values in RSA what's the key what are the variables we use to denote the key RSA you think of Diffie-Hellman remember RSA when we what's the public key what are the letters we use E and N remember with RSA N is the modulus mod N so that's part of the public key and the other value is this value E the exponent that we use so the value of E and N is included here if we're using Diffie-Hellman then we have the public values Y and the parameters the alpha and and Q in Diffie-Hellman we have some unique ID some long unique ID for the authority and the user the issuer and the subject we may include some optional extensions to give him more information but not we're not going to cover that and then finally the last part is the actual signature so we take all of this above we use the hash algorithm to find the hash value and then we encrypt with the authority or the issuer's private key and the result is the signature that's our certificate let's have a look at some examples so one place where we use certificates a lot is on secure web access so when you access a site using HTTPS the issue is that with HTTPS we want to encrypt the information between your browser and the web server so that no one in between can intercept and see the information for example the web server for your bank so between the browser and the server we want to encrypt the information so why do we need a public key well we can use a public key to verify that we're communicating with the bank and we can use that public key to encrypt a secret key and then use that secret key to encrypt our information so we need the public key of the server so if I find the public key of the server then I can choose a secret key and encrypt that secret key and send it to the server and then our data can be encrypted with that secret key so when I access a secure website the normal procedure is that I obtain the certificate of that website let's have a look at the certificates the exact protocol for doing it we'll see in a later topic okay but let's just look at the content of the certificate so let's access some secure websites and we'll give two examples so here's one of one of my websites and in the HTTPS to indicate I want to use a secure connection between my browser on this computer and my server somewhere else and it connects fine and note in this case Firefox shows this padlock up here giving some indication that there's some form of security what's it say when I hover over it says verified by start com if we click on it it gives me some information you are connected to a particular domain name sanderlands.info so it's confirming and we'll see later the certificate is coming from this domain name which is run by unknown so there's no information about who the owner of this is but it's coming from a particular domain name and it's verified by start com some other company so in this case when we'll see the details this is this information is coming from a certificate for sandylands.info where the authority is start com and it says your connection to this website is encrypted to prevent eavesdropping which means that we've used this certificate to then exchange some secret key and then everything we send between the browser and the website is encrypted let's look at some more information so there's a more information about that connection and actually before we look at it some identity of the website so it gives uses a domain name to identify it and the in this case the owner the website doesn't supply ownership information it's just the domain name that identifies it the owner it could be someone's name it could be my name but it's not in this case and the verified by is the authority in this case and we can actually view the certificate before we do it we see down the bottom some other information about the security the connection between the browser Firefox and the server is encrypted using AES 256 256 bit key and it's just some information about that now let's look at that actual certificate and Firefox shows some general summary information but let's look at the let's look at that first and then go into the details so this just shows a selection of the information the the name of the subject who this certificate is issued to is in fact broken into different fields there's a common name the domain name of the website and optionally can be an organization or organization unit for example it could be a common name of SIT and the organization is SIT the unit is the school of ICT or something similar so you can identify the organization as well some serial number that is given for that the subject the user in this case and then issued by is the authority who issued this certificate and some common name for the authority start com class one primary intermediate server CA and some organization name issued on 11th of June 2012 expires on 11th of June 2013 so this is valid for one year this certificate after 11th of June 2013 when your browser receives this even though the signature may verify it should also check the expiry date and if the date is past this it shouldn't accept this certificate it's no longer considered valid and the fingerprints are used for the the signature let's look into some some of the details so this is actual fields in inside the certificate so I'll select the field here and we see the value here I know it's small but we can just make out so the version of X509 being used in this case is version 3 the serial number for this certificate which was created by the issuer when the certificate was created the algorithm used to sign and remember with the algorithm with signing there are two parts the hash and the public key cryptography so this is using char one and RSA encryption so you can use different algorithms you're not fixed to a particular algorithm you can use char two five six char five one twelve different algorithms here you can use RSA DSA other public key algorithms then the issuer that's the authority and it's broken into four fields the common name organization unit organization country and the two dates it's not valid before this date and time and not after this date and time and the subject is who the user is it's got an email address a common name and a country not all fields net and needed in the certificate I think this object identifies just some some encoding of the information included there it would depend upon what fields are included so that identifies the user or the subject then we have the public key info this is the public key of the user the subject what algorithm is used for the public key and here we gain again use RSA it doesn't have to be the same as the signature the public key here is chosen by the user they choose whatever algorithm they like RSA DSA some other algorithm the signing is done by the issuer of the authority again they choose whatever algorithm they like so they may be different it's just they are the same in this case both use RSA because RSA is very common and here's the public key and you can see the modulus which is n in the public key 4096 bits is the size of n in this case and if we scroll down it's presented in hexadecimal and e the exponent and here is just 65537 so it's a very common value of e with RSA the value of e the exponent is usually this value or some other well-known value it doesn't have to be different but the modulus n must be different so there's the public key extensions we will not go through them you may include some other information signature algorithm and importantly the signature itself that's it that is we take the hash of all the other information and then encrypt it with RSA if we write down the entire certificate we started with a version then we had some other information the issuer subject so all the other fields we take all of them combine them together all of this what we just went through and then at the bottom we attach the signature or the end we attach the signature which is we take the hash of all of this and then encrypt and in this case we encrypt with a private key of the authority we take the hash of all the information encrypt with a private key of the authority in our case the hash function is char one and the encrypt function is RSA and this value here the signature is the output of this the hash the char one of all this information the previous fields and then encrypted with the private key of the issuer start common this case and we get this 2048 bit values at output so that's the signature so we that's the entire certificate for this this website a web server so when the server sends me this certificate sends my browser this certificate how do I verify it how do I know it's valid what do I do I decrypt decrypt the signature with the public key of of the authority and the authority in this example it was start com let's scroll up just remind us the issuer the company's called start com so I decrypt with the public key of this organization where is that public key did you did I encrypt it decrypt it when I use my browser does the user have to do it no it should be automatic where's the public key of start com so to verify this certificate it was signed with the private key of start com to verify I use the public key of start com therefore I need to know the public key of start com where is that no that's the value of e where is the public key of the issuer in this case it's not in the certificate the certificate contains the server's public key in here was the the public key of the server where's this public key of the issuer again the browser knows it it's pre-configured in the browser so when you access a web server that web server sends you its certificate you need to verify it or your browser needs to verify it to do that your browser needs to know the public key of the authority and a common way that that's performed is your browser is pre-configured with a set of public keys of authorities and in fact not just public keys of authorities but certificates of authorities trusted certificates let's have a look why won't you close wrong button so now let's look at that was the certificate of the web server that my browser received to verify and you can see it in Firefox under preferences here I'm under advanced encryption and I can view certificates and there are a number of tabs tabs up the top the one I've selected is authorities these are at least most of these came when I installed Firefox these are a set of certificates of different authorities that my browser trusts and inside those certificates are the public keys of those authorities so we must start with some public keys to be able to verify something that we receive so there's a bunch of authorities that my browser trusts some of them you recognize their names some are companies government organizations Komodo is a large security company Digi cert and trust is another large one let's but we our certificate was signed or issued by start com let's see if we can find them okay and was it this one I think the certificate the issuer was start com I can't remember was class one or class two but one of these two so there are multiple certificates for this organization so we can actually view that certificate as well and it's the same format so let's make note of what we've got so far my browser received my browser received a certificate for sandylands.info that was the website I contacted and I'll write it as that's the user or the subject and the issuer was start com and specifically I think it referred to start com class two primary intermediate server that was the issuer in that case that the public key of that user is needed to verify so now I go into my browser and I see the set of certificates I already know about and trust so these authorities are the authorities my browser trusts and I find this certificate here for start com class two so start com summarized class two this notation is just sure hand to say that this is the user this is the authority certificate for sandylands.info signed by start com class two and now we see that's certificate for start com class two who's the issuer who signed it well at least here that issued by in this case start com certificate or certification authority so this certificate is signed by someone else same company but a different certificate CA let's call it and we could check the details in here has a validity so now let's see whether we trust who signed this because to verify this first certificate I received I need the public key of this organization well the public key is inside here but this public key is being signed by start com CA and we also see in my browser in fact I trust that that specific certificate already but let's just check start com CA is a built-in object it's already in my browser so to be complete we have a third certificate start com CA and if we looked at the details who signed this who look at the the subject issued to and the authority issued by I know it's hard to see at the back it's the same organization start com certification authority start com certification authority this is a special case certificate what would say self-signed the same person who whose public key is included issued or signed that start com CA we'll return to that a bit later self-signed certificates but coming back to the start my browser received this certificate I want to check if the public key of sandy lens info is valid to do so I need the public key of start com class 2 and I look in the set of trusted certificates inside my browser for the certificate of start com class 2 and I find it there and therefore I trust the public key of that organization I use the public key of start com class 2 to verify the received certificate and if it verifies then I trust the public key now of sandy lens dot info and then I can use that public key to encrypt information between my browser and the server so important point here for this to work in practice your browser must be pre-configured with a set of certificate authorities and we see in here most common browsers have a large list of different authorities different companies and government organizations vera sign is another large one in fact there may be different authority certificates visa you'll see Microsoft and other organizations in there if you don't trust this organization or this certificate then you need to remove it from your browser and now that I trust the public key of sandy lens dot info I can encrypt a secret key to use for our data encryption any questions on the concept so far of certificates so remember it contains a public key of user my certificate contains my public key but importantly it is signed by some authority and when someone receives my certificate they need to verify it and to verify it they need the public key of the authority and okay yep so the question about in this last case we had a certificate signed by the same organization as it's issued to which is called a self-signed certificate so long as the browser accepts that so the the list of certificates here on this authorities tab are the ones that your browser trusts so if there's a certificate in this list then your browser will trust and use the public key from that list but if we'll see later a case of a self-signed that's not trusted and come back to that one okay after the break you'll be happy to answer some quiz questions about certificates make sure you remember contains a public key certificate contains a public key plus other information but importantly a public key of the user and it's signed by an authority and to verify it we need the public key of the authority and it turns out later we'll see we can have a chain of certificates that is we could consider these as a chain of certificates in that here's one public key signed by one authority and that authorities public here is signed by another authority and that authorities public here signed in this case signed by itself we can actually have a chain of certificates but we'll cover that after the break let's stop there and then we'll try and demonstrate with some examples different aspects of certificates after the break if we okay let's have a quick example if we what it what will happen if we access a website and we we receive a certificate but there's no start com class 2 for example in there let's try let's visit the IT server HTTPS IT dot SIT I think I have to reload sorry my internet's gone let's try again maybe it was working at the start of the lecture let's do that and show you after the the break okay let's have a break and we'll see if we can get some internet access and I'll show you the case what happens if we don't trust the certificate okay let's continue later see what's wrong