 Authentication. So the purpose of authentication. Alice wants to be sure she received data from Bob and not from somebody else. And Bob wants to be sure he received the data from Alice and not from somebody else. So this is basically symmetrical. They want to ensure who is talking to who. Agenda for this part. First we see that authentication could be addressed with symmetric cryptography and has symmetric cryptography again. Then we'll talk about the risk of impersonation and to finish with the out-certificate authority could mitigate this risk of impersonation. Authentication could rely on two mechanisms. Symmetric encryption has symmetric encryption. Principle will be always the same. Alice will choose a random value and we can call this challenge and we'll share it with Bob. Bob would return the encryption of this challenge and then Alice could check the result to ensure about Bob and identity. With the hash mark. So here we've got Bob and Alice. We are in a symmetric cryptography so they have a common choice equate this golden key. Alice will choose a random value, the challenge, and send it to Bob. Bob will concatenate his golden key value with a random one and then we'll put this in a hash function. So we will have a digest and we'll send the digest to Alice. Alice, symmetrically, would take the random value. We'll concatenate with the golden key, put it in the hash function, and get a digest. Then she can compare the digest value. If they are the same, she is sure she received data from somebody who has a common shared secret. So it's only Bob. He don't have this secret and nobody should have it. So she is sure it's Bob. Another way to do it could be with a high S and here we will do some encryption. So Alice again choose the random value, the challenge, send it to Bob. Bob this time will encrypt with a golden key this random value and will return this value encrypted. So Alice could decrypt it and compare the value. It's the same. That means she's talking to somebody who has the same common secret. Always the same mechanism, quite simple. Now let's see with a asymmetric one. In the asymmetric context now Bob and Alice got key pairs, a public key and a private key. So Alice for the authentication choose a random value, the challenge, and share it with Bob. Bob will apply the signature process with this private key. You remember the signature process for the very side, just a hash, then an encryption of this hash. Then Bob will send this signature to Alice. Alice will check it. For that she need what? The public key of Bob. Okay, it was with the public key she can decrypt the signatures, get a hash and check the hash of the random value. This is a signature check. If the signature is okay, that means she's talking to Bob because she's talking to somebody who has the capability to generate signatures, so the private key. Now I would like to tell you about the risk of impersonation. Here you've got the basic scheme of authentication asymmetrical. You've got some public keys that are published, the Alice one, Bob's one, and they've got their own private key. But what happens if, if, distribute a public key like the Bob's one? It could be simple on the internet. Just say, okay, this is the Bob's public key. Take this one, and you can do the authentication now. If I take the schematics we've just seen before, here everything's working well. Signature is okay, and Alice thinks she's talking to Bob. So the question is how Alice could be sure that Bob's public key is not if's public key or somebody else. This is a problem of impersonation. So how can we trust the Bob's public key? And in fact, the answer would be with certificate and certificate authority. This is the last part we will see together. Certificate and certificate authority. First, let's define what is a certificate. Certificate is a digital data that included. Issue your identification, certificate identification, a public key, and a signatures of all the previous data. So if you will remember what we see before, to generate the signatures we need a private key. So I would say someone is the owner of this. The one who is the owner of this is the certificate authority. The certificate authority is in charge to generate the certificate. Generate the certificate is generate the signatures that is embedded inside the certificate. So now Bob won't distribute only its public key, but its certificate. We will see just after how we can check the signatures of the certificate and ensure that the public key is a good one. Now I just give you the most known certificate format, X590, just to let you know. And it's saying the certificate and certificate authority that we are able to exchange public key in a trusted way. So let's see the different step for this. OK, the first step will be that Bob will require a certificate to the CA. To do that, you need to communicate in a secure way with the CA. He will provide his public key and the CA will put all the information together and generate the signatures. Thanks a private key. Now you will know this. Signature plus those data, it's a Bob certificate. So now Bob won't provide any more only his public key, but his certificate. Inside the certificate, there is a public key again and a signature of it. And Hallis or anybody could check the signatures that is inside this certificate. Thanks, the public key of the CA. You could tell me, but if replace the CA public key, it will work some impersonation easier. In fact, CA is an independent certificate authority. I would say it's a well known one. It's known by anybody. So you can't substitute key or certificate. So at the moment or another, you have to trust somebody. You have to have a starting point when you say, OK, this one, I'm sure this key is valid without doing some check. It's something you have to rely on it. Now, Hallis will check the Bob certificates. As you can see in the picture, we've got the CA and the public key of the CA is distributed as a certificate also in the public domain. We don't have any more just a simple key, but always a certificate. So we could imagine that we can also check the CA certificate with another CA certificate and a chain of certificate. But to simplify here, I just want to have one level. So Hallis will take the Bob certificates. She's got a signature value. So she wants to check the signatures to do that. She will need the public key of the CA, which is made in the CA certificate. She can check the signatures. If the signature is OK, she can use the Bob public key and is sure that it's Bob public key. Let's have a full picture of the Bavic authentication with the CA. Hallis sends a challenge to Bob. Bob do a signature of this random value thanks to his private key. Then he sends back this signature to Hallis. Hallis first will check the Bob certificate. So for that, she needs the CA certificate, which allows her to check the signatures inside the Bob certificate. If the signature is correct, that means the public key of Bob that is inside the certificate is a good one. So now she can use it to check the signatures of the challenge. It works. That means the challenge was OK. So Hallis now is sure to talk with Bob. Now we finish with the authentication. If I sum up, authentication is done thanks to the challenge and you can use some symmetric or asymmetric cryptography. If you are using asymmetric cryptography, there is a risk of impersonation. And to mitigate this, you can use a certificate mechanism and a certificate authority, which delivers certificate. If the both sides authenticate each other, we are talking about mutual authentication. I give you this warning because it's commonly used.