 And I hear everyone asking, what about Diffie-Hellman? If you look at the lecture notes for public key crypto, you'll see we missed a few slides on something called Diffie-Hellman and other public key ciphers. So we covered RSA for public key cryptography. There are other algorithms. One that we'll cover later is the Diffie-Hellman Key Exchange. So that's in the slides we've skipped over. We'll come back to that when we look at how to exchange keys, key management. So we see that public key cryptography is used in encrypting data. It's especially used in authentication and key management as well. So we'll return to public key crypto soon. But this next topic signifies a shift in what we're trying to cover with cryptography. We'll talk about message authentication codes, but first, some common or general types of attacks on communications in a network. And we've seen these, although with slightly different names in one of our first lectures in the semester, the general attacks message disclosure. That is, I send a message and I don't want anyone else to see the contents, but an attack discloses the contents of those messages, that message. That's bad. And how do we stop that? Encrypt the message. So that's the technique to prevent disclosure is encryption. So if you encrypt the message, if you're using a strong algorithm, one that doesn't have flaws and you do it correctly, then it should be impossible for someone to find the original message, even if they can intercept the communications because they need the key to decrypt. So we've gone through symmetric key ciphers and public key ciphers for encrypting messages. In practice, encrypting data, large amounts of data is primarily performed using symmetric key ciphers, not public key ciphers. There are some performance reasons for public key ciphers. Don't work fast enough for large amounts of data. So we have a technique to prevent this disclosure. Now, maybe this is not complete. This is not complete traffic analysis. We haven't talked much about traffic analysis. We send our encrypted messages, but someone tries to observe the patterns of communications. We haven't really touched upon techniques for dealing with that, and we won't, in fact. Some using encryption helps, but you need to do more than encryption to prevent traffic analysis. And sometimes it's hard, but things like adding extra padding to your data, adding in random messages such that when someone analyzes the messages, they don't see any pattern in your behavior. We haven't touched much upon traffic analysis, but there are techniques that can deal with it. Let's look at some of the other attacks, masquerade. I am Tanarak. I come here, I say, I'm Tanarak. Well, how do you know I'm not? So you need some way to authenticate the person you're communicating with. So masquerade attack is to pretend to be someone else. Other attacks. How do we stop a masquerade attack? We need to perform some form of authentication. Really authenticate the source. Confirm that the source that we're communicating, who sent us a message, confirm that they are who they say they are. Content modification. I send a message, someone intercepts, modifies the message, then forwards it onto the intended destination. How does the destination know that the message they received has not been modified? We use authentication. Similar modifications. They don't modify the message, but they modify the ordering of messages. Let's say we send five messages. One, two, three, four, five. And the ordering has significance. Such as the attacker changes the ordering of the messages in which they're delivered at the destination. How do we detect that at the destination? Authentication. And similar delaying and changing the timing at which messages are received, timing modification. We use authentication to do that. So we're making a shift from encrypting our data to keep it secret, to avoid disclosure of the data. That's what we're focused on so far. We're now going to look at authentication and different forms of authentication. And some specific forms of authentication will be the last two. Repudiation. Remember non-repudiation is the service that we want to make sure that no one can deny their communications. So source and destination repudiation. So the source cannot deny that they send a message, and the destination cannot deny that they've received a message. There are some two services that we often require. And we'll see a special case of authentication. What we refer to as digital signatures are used there. So this topic and the next, I think one or two topics, talk about different techniques for authentication. So generally authentication. The receiver wants to verify that what they receive is authentic. What does that mean? We often break it into two parts. We want to make sure that the message has not been modified. Someone sends us a message, the one I received. I want to make sure that no one's modified it along the way. So data authentication. Authenticate the data in the message. The other form is that we want to make sure that the message came from the person who they are claiming to be. I receive a message from, and it says in the from address that it's from this person, from Tanarak at s-i-t dot t-u-a-c-t-h. When I receive it, I want to be sure that it is from Dr Tanarak. It's not from someone pretending to be him. So authenticate the source. Slightly different aims, but in most cases the similar techniques are used to implement data and source authentication. So we often mix them. We usually will have one technique that provides both. So what are the different authentication approaches? And we'll go through them. Symmetric key encryption. Encrypt our message. So we'll explain how that provides a form of authentication. Turns out using encryption sometimes is not what we want because A, we may not want to encrypt the message and B, the algorithms that we have available may not be appropriate. Maybe too slow, too costly. So there are some other specific techniques that don't necessarily encrypt the data, but also provide authentication. So we'll look today at message authentication codes. Max. Don't confuse with an Apple computer or a medium access control or if you've sat in on some of my other classes, mandatory access control. This Mac, abbreviation is used for many different things. Here we refer to message authentication codes. So we'll talk about what they are. Hash functions are important for authentication and we'll use hash functions. Everyone knows hash functions? So hands up if you don't. That means that we will skip that and you'll be able to answer questions in the exam about hash functions. Good. And we'll see how hash functions are used in public key encryption and get to digital signatures. Those two hash functions and public key encryption will be in the next set of slides. First, let's see how we use our known techniques for encryption to provide also authentication. So symmetric key encryption specifically. This figure. I've got a message. I want to send from A on the left to B on the right. Normal way to encrypt the message. I take the message. I use a symmetric key cipher, E. I use a shared secret key K. I encrypt the message. I get some cipher text. The cipher text is sent across the communications medium and the destination decrypts using the decryption form of the algorithm and using the same shared secret key to get the message. That's known. That's how we encrypt our data. It provides confidentiality in that only B can decrypt the message. Someone who intercepts the cipher text so someone who intercepts the communications between A and B even though they have the cipher text so long as we're using an appropriate algorithm they can't find the original message because they don't have the key. So you need the key to get the message. Therefore, the message can only be seen by B. Only B can decrypt. Well, A can also decrypt but A had the message at the start anyway. So A and B know the contents of the message and no one else in the world knows the contents. But that's not authentication. That's confidentiality. That's preventing disclosure of the messages. We want authentication. Well, it turns out this also provides authentication. B receives the cipher text. B wants to make sure in terms of source authentication this message came from A. So B receives the cipher text. They need to be sure it came from A and not someone else pretending to be A. So when B decrypts using key K if it decrypts successfully it means the cipher text was encrypted using this key. And the only other person who has this key is A. Therefore, the message must have come from A. Unless B sent the message to himself, unlikely. So it turns out using symmetric key ciphers we also confirm that this message come from the other person that has the shared secret key. If... Let's see if we've got a few more slides to explain that. Oh, we'll explain it with the slides. Okay, we'll come back to that one. Similar with data authentication. If the message decrypts decrypts successfully when I say decrypt now I mean that when we decrypt the cipher text we get plain text that is correct corresponds to the original plain text. If it decrypts successfully it means the cipher text I received must have been encrypted with the shared secret key that A also has and that is the source authentication and that hasn't been modified because if the cipher text was modified in some way it would not decrypt successfully. So it also provides data authentication that is we can be sure that the message hasn't changed along the way. It provides these two forms of authentication under the assumption that the person decrypting can recognize the correct plain text or that they are sure that the decryption works successfully. So how do they do that? So we'll cover these two again and consider this assumption. Here's an example. I want you to answer the two questions. So B, you are B, okay? You are user B. I've just sent you a message. You've received something and here's the cipher text you received. D, P, N, etc. You think it's from A, okay? You think it's from A, therefore you decrypt that cipher text using the key that you've shared with A. Let's call that key K, okay? So K is the key that B has shared with A. Decrypting this cipher text produces this plain text. Do you think the plain text is correct? Yes, maybe. Someone said yes. Some people say yes. Some maybe. Anyone know? Well, it doesn't look incorrect. The messages that we send have some meaning. No one sends random messages to people because if you're sending random messages then you're not communicating any information. So with a message that we receive when we decrypt and get the plain text that message must make sense. Now what makes sense? Well, it depends upon the context of the communications. In this case I think you would assume that this makes sense. In the context of the communications this is a valid plain text. What if we used a different key? Well, we've seen and we've seen in some of our classical ciphers. Remember when we did the brute force attack on the Caesar cipher? We tried all 26 keys. Very simple cipher. One of the keys produced some English message. The 25 other keys produced some random looking characters. And that's the property that we'll assume that exists with our ciphers. When we decrypt using the wrong key we take our cipher text, decrypt with a key which is not the correct one that was encrypted with we'll get random looking cipher text. In this case we didn't. We got some structured, sorry, random looking plain text. Here we got some structured plain text. Therefore it's reasonable to assume that because this cipher text decrypts to this plain text that makes sense then it means this must have been a plain text and it means this is the correct key. Who else has this key? A and B are the only ones who have this key. It's a shared secret key between A and B. Therefore when B decrypts with this key unless B sent the message to himself it must have come from A. So it performs source authentication. Only A has that key. Therefore only A can encrypt the plain text to get this cipher text. Therefore when we decrypt this cipher text with that key and get the original plain text we confirm it came from A. So we'd assume in this case because the plain text makes sense it was encrypted with the key. And hence therefore came from user A. Therefore we know who it came from. What about if it was modified? Same concept. If we sent some cipher text from user A but someone intercepted and tried to modify that cipher text and then B receives the modified cipher text and tries to decrypt with key K it's very unlikely to get some plain text message. If we try and decrypt the modified cipher text with the key we'd get random output. Since we didn't get random output it means this message hasn't been modified. So it implies that the cipher text received is the same as what A sent which is data authentication. Same concept, different example. You receive this cipher text, your B, you decrypt with the key that we'll share with A and you get this plain text. What's your conclusion? Plain text is these characters here. This F, T, U. What can you conclude when you get that plain text? So you've decrypted some cipher text with a key that you shared with user A. You think this came from A? Can you make some conclusion here? It's been modified. Some things being modified is one possible thing. Why do you say that? Because this doesn't make sense. So the first thing to notice is that the plain text that you get doesn't make sense. So you think something's gone wrong. If I decrypt cipher text with the correct key I should get plain text that makes sense. But I didn't. That implies either someone modified the cipher text along the way because if it was modified when I decrypt with the key I'll get something other than the original plain text or I'm using the wrong key. Here's the cipher text. I'm using the key shared with A. But maybe what happened is that user C created this cipher text using their other key, their key. But I think it came from A. So I decrypt with the key shared with A but I get something that doesn't make sense. Now I conclude it's possibly came from someone pretending to be A. It's not from A. I don't know which one went wrong. It's possible that either the cipher text was modified or it came from someone else using the wrong key. In either case, I don't trust it. Okay? So we know something went wrong. Either the source is not authentic or the data is not authentic. In other cases, we don't trust that. And it's because the plain text doesn't make sense. Whereas in this one, the plain text made sense and therefore we trust it because it must have come from A and not been modified. Unfortunately, not all of our messages we send in the internet or in communications are nice easy English messages. Sometimes we send images and so on. Binary. What's the outcome? What's your conclusion? Can anyone conclude? Here's the cipher text you received. You decrypt with this key and you get this plain text. Welcome. What's your conclusion when you get this plain text? Are they the same? They're not the same type. Yeah, but so someone sent you an image. This is a portion of an image. You don't know. That's the right conclusion in this case but so far, we're saying to authenticate we need to be able to recognize the plain text. In this case, I can. In this case, I recognize it's not English and it doesn't make any sense in any other languages you may know. This one, well binary, what are we looking for here? The point is that we must be able to identify some structure in the plain text. Even if it's not English, there must be some structure that we can identify to be able to confirm that this is the correct plain text. In this case, we could. The structure is that there are words in the English language that combine together to make a phrase that makes sense. In this case, there's no such structure. In this one, I don't know. So in general, to authenticate we need to make sure that the plain text has some structure that the receiver will recognize. So this is just a summary of those examples. Example one, we concluded that it was sent by A and had not been modified. Example two, because it had no structure in the plain text, we concluded it either was not sent by A or it was modified. Therefore, don't trust it. Example three, I can't visually recognize any structure so we don't know whether it's correct or incorrect. Which leads us to the point that whenever we send a message, we must ensure that the receiver can recognize some structure. We must make sure that there is structure in the plain text. If your plain text is English or some language, then usually you can recognize structure as a way to check the structure. But we'd like to automatically do it. That is, we'd like a computer program when it decrypts to be able to confirm, yes, correct, no, incorrect. How do we do that? Well, if our plain text doesn't have structure that we can automatically do that, we can add some structure. Add some extra information to the original plain text such that when we decrypt we can use that extra information to check if it's correct. And there are different ways to do that. Some things are built in. For example, if our message is actually a network packet like a TCP segment, TCP segments have some structure in the header. They have fields which are always present so we can use that to recognize. So some things have structure present. If they don't, we add some structure like an error detecting code or a frame check sequence. And you have seen these in different computer applications. Add some extra bits such that when we get the plain text we can use those extra bits to confirm that this plain text is indeed the original plain text. Parity checks are a very simple form of an error detecting code. You would have heard of CRC16, CRC32 as an error detecting code for computer data. And there are other ways to do that. So we'll assume from now on that there is a way to recognize the plain text. We'll come back to this. We'll make this assumption. Whenever we decrypt something we can recognize whether we have the correct plain text or whether we have the incorrect plain text. We'll assume there's always a way to do that. And it's practical to assume that. You've used OpenSSL and DES and some other ciphers to encrypt. Let's just encrypt something just to give an example. I have some plain text message. It's 72 bytes in length. There's plain text message. Let's encrypt it. Encrypt with let's just say DES. The input is the plain text and the output is my ciphertext. Sorry, it's wrapped across the line. I just named the output. Sorry, the screen is not... Using OpenSSL encrypt using the cipher DES, ECB mode. Input plain text is the file plaintext.txt. Output ciphertext is the file ct1.bin. I haven't supplied a key or an initialization vector. We can, but in fact OpenSSL will actually prompt me for a password if I don't. And I need to enter it twice. So if I make a mistake typing the password it will tell me that. And it encrypts. So if you don't supply a key with OpenSSL it will ask you for a password. And it uses that password to generate a key. And the algorithm for doing that is not so important for us. Not at this stage yet. How long is the ciphertext going to be? How many bytes in the ciphertext? The plain text was this message. It was 72 bytes long. When we encrypt with DES, ECB what do you think the ciphertext is going to be in length? 32? No? Well... 72 bytes of plain text in what are we going to get as an output? In length. Give you a choice. Less than 72, the same as 72 or more than 72? More than. Alright, let's go to the answer. It's not going to be less than. Now remember with block cipher. DES is a block cipher. DES takes 64 bits in of plain text, produces 64 bits of ciphertext. Now with a mode of operation, ECB, that's how it takes 64 bits and gets the next 64 bits of ciphertext and then another 64 bits of plain text and 64 bits of ciphertext. So at least the ciphertext length is going to be at least the same length as the plain text. Because we have the same length input, same length output. So it's not going to be less than 72. It's going to be 72 or more. Why would it be more? Padding. Or different reasons in fact. If our input is not a multiple of 64 bits DES always takes 64 bits in 64 bits is 8 bytes. So if it was not a multiple of 8 bytes plain text, then we need to pad that extra last few bytes of the plain text to make it 8 bytes. Is it a multiple of 64 bits? 72 bytes in? How many blocks? 64 bits is one block 8 bytes one block. Our plain text is 72 bytes. How many blocks? 9 72 bytes of plain text 1 byte. 72 bytes of plain text 8 bytes is one block therefore we have 9 blocks 9 blocks and even number of blocks so we don't need padding. Let's see how long the ciphertext is. 96 bytes Let's have a look at the ciphertext. Of course I cannot open it in a text editor because it's going to be random characters. So I need a hexadecimal display. Just a program to display the content in hex. There's the ciphertext. It's got some salt in it. It's a salted password it was used. So let's explain what happened. 72 bytes input 96 bytes in the ciphertext where do these extra 4 bytes come from? They come from 3 different things. Firstly I used a password and the password is used to generate a key. Remember Desk takes a key as input but I used a password. This salted is of course readable by anyone and it's actually the first 8 characters here. It's a special string to indicate to the one decrypting that this was obtained using a password. If I used a key this would not be here. This is to say that when you decrypt you need to ask the user for a password and we may not cover until the end of the course the way that you store passwords is you don't store the password you actually store almost an encrypted form of the password using some other value called assault. The next 8 bytes and again it won't make sense to you but these 8 bytes are for storing the password for supporting the use of the password. So the first 8 bytes indicate that we use a password the next 8 bytes are to support the use of the password. So we had 96 bytes minus 16 that leaves us with 80 bytes but the cipher the plain text was 72 bytes we've got 80 bytes what is the last 8 bytes so to summarize so far plain text 72 bytes we expect the cipher text to be 72 bytes okay the cipher text is 72 bytes plus 8 bytes of the salted string plus 8 bytes to support the password 72 plus 8 plus 8 is 88 bytes but there's another 8 bytes to bring us to 96 and OpenSSL added some structure to the plain text it added an error detecting code so that when OpenSSL decrypts it can automatically detect whether it's correct or not so it doesn't depend upon whether the plain text is English an image or whatever when OpenSSL decrypts if the message was modified or if the wrong key was used it will automatically use what's called the error detecting code those last 8 bytes to detect if it's correct or not let me decrypt if it prompts for the password why because when I decrypt it recognizes these first 8 bytes mean you must use a password not a key I type in my password what's it say bad decrypt some error message it didn't work can we look at the plain text I don't know if it even produces there's the plain text from decrypting this is the plain text I entered the wrong password so what happened I tried to decrypt the cipher text it prompted me for the password I typed in the wrong password and OpenSSL decrypts using that password but then checks the structure automatically it detects using the error detecting code if this is correct or not and it says no bad decrypt didn't work it doesn't do any analysis of the English it just uses the error detecting code to automatically check that this is incorrect plain text and in fact we can see that this is incorrect plain text if I decrypt again but use the correct password it doesn't report an error message and we've got the correct plain text so in practice encryption software usually adds some error detecting code such that when someone decrypts it it can be automatically detected if this is correct or not so that was an example when I entered the wrong password of the source authentication working if I enter the wrong password to decrypt it means I'm not the person with the original password or the wrong key is being used so with symmetric key encryption we actually the focus is on confidentiality but we also provide authentication we can confirm who sent it and we can confirm that the message hasn't been modified any questions on so far with symmetric key encryption again we're trying to make sure that everything's authentic nothing's been changed no one's masquerading as someone else any questions if we don't add the password we'll have just 80 bytes yes correct correct with so you don't need to use a password normally you'd use the actual 64 bit key an initialization vector and we'd take the 72 bytes of plain text encrypt to get 72 bytes of cypher text plus there's these 8 bytes for the error detecting code so OpenSSL automatically adds these 8 extra bytes so we can check when we decrypt there are other ways to authenticate the problem with using encryption is that we need to encrypt the entire message let's say I have a 40 gigabyte file okay I want to transfer the file to someone I don't want it to be secret okay I don't mind if someone sees the contents but I want to make sure or the person that receives the file wants to make sure it hasn't been modified and it came from the correct source they want to be able to authenticate that what they receive is valid we don't care if someone sees the contents so encrypting the entire file is helpful in this case it takes time to encrypt encrypting a 40 gigabyte file would take I don't know minutes possibly so often we don't want to encrypt the entire content so there are other ways that can provide authentication we'll look at message authentication codes what we do is that we take our message M that we want to send to someone we have a shared secret key so both A and B have this shared secret key K and we use some function some other algorithm called a MAC function the terminology is a bit confusing here but it's often just called a MAC function but some algorithm that takes the message and the key and produces a short a small fixed length output T in this case now also called a message authentication code but maybe to avoid that confusion let's call it a tag sometimes called a tag so we take our message apply this function with a shared secret key K and the output is some tag T now this is similar to encryption let's try and remind you the algorithm for encryption when we encrypt we say we take we have user A and sending to user B encrypting what do we do we take let's say K shared between A and B a shared secret key between A and B we take our message and we encrypt using that key our message and what do we get as output ciphertext alright, message sometimes we write P P for plaintext, message M for message, same thing that's normal encryption, symmetric encryption and we send the ciphertext and we're just seeing that that works for authentication and we send that to B that's the previous one c is sent B decrypts but now we're using a different approach we take our MAC function some other algorithm a shared secret key I don't know also K, A, B the message and we get a tag as an output so A as a message to send to B they take the message a key, a secret that's shared between A and B and some algorithm I'd generically call this MAC same as here the encryption algorithm is E and it produces some output first look at the similarities here message is input message is input shared secret key is input so they both techniques take the same inputs what's the difference then the difference is in the algorithms used here they have different characteristics different properties and one noticeable thing is that with encryption the ciphertext as output is the same size as our input plus maybe some error detecting code but with a MAC the output tag is small and fixed length so that's the difference of how the algorithms work so T is not the same size as M T is small and fixed in length and depending upon the algorithm as to what the size is let's say 128 bits maybe the length of T if our message is 40 gigabytes using encryption the ciphertext is 40 gigabytes with a MAC if our message is 40 gigabytes the tag produces output maybe say 128 bits so although they look the same in the way that we write them they are operating differently we send the message and the tag to be the destination we write it as message concatenated with the tag that is we take the original message and then attach to the end of that the tag that we've generated and send that to B and then B needs to authenticate that is they need to go through the steps to verify that this message came from A and that hasn't been modified and we'll see how that works in a moment so this is one way we use a message authentication code a MAC first no confidentiality here anyone can see the contents of M so someone intercepts here they can see M we're not trying to keep the message secret that's not our objective if it was using this approach is wrong so here we're just trying to make sure that the message B can verify it came from us and it hasn't been changed so we send the message in the clear we say as well as the tag whereas when we use symmetric key encryption the message was secret so there's a different in features there what does B do when we used encryption what did B do they simply decrypted they let's write it as they take their decryption algorithm the same shared secret key so this was the procedure we used before the ciphertext and they get a right M prime as the output B thinks it came from A therefore decrypts the ciphertext with the key shared with A and they get some output M prime and if this makes sense then they trust what they've received and it's authentic that's the previous approach what do we do with the tag and message authentication code how do we authenticate we take the message we received and we calculate the MAC for that using the shared secret key KAB and I'll explain MAC M prime in a moment instead of M I try to distinguish A has the original message M they send it across the network maybe someone modified it it's possible someone the attacker tried to modify it so to distinguish from the one that was sent and the one that's received by B I'll say the one received by B is M prime it should be the same as M they should be identical but in some cases they may not be M prime just means this is the received version so what B does is they take the received message they think it came from A so they apply the same MAC function that A used using the shared secret key KAB and they get as an output another tag T prime and then what then they do a check if the calculated tag T prime equals the received tag everything's okay that's the concept there so we're first going through the process that we use to use the MAC and the tags and then we'll see how it provides the security so B receives the message along with the tag B calculates the MAC of that received message using a shared secret key with A and they get some calculated tag as output and it should be the same as the received tag T if it is then we assume everything's okay if it's not we assume something's gone wrong we don't trust it so we need to look at the properties required of the functions such that that works that it provides authentication any questions so far so we need to look what if the attacker what possible things the attacker can do to do an attack and one thing maybe to modify T so we'll see that the attacker if they modify the tag I'll draw it a bit later and we'll see on some slides but if we modify the tag what it does is they calculate the MAC of the message received they get some tag they compare it to the modified tag and they will be different we'll see the properties of our MAC function should be such that the MAC of two different messages will give different tags let's go to that property and then see why that attack won't work we'll return to that picture in a moment the tag I don't know if it's on the slide here the same with encryption when we encrypt a message with two different keys we'll get two different ciphertext or if we encrypt two different messages with the same key we'll get two different ciphertext so if we vary one of the inputs we'll get a different output the same property is in the case with the MAC if we use a key and one message one tag if we use the same key and a different message we'll get a different tag that's the required property of the MAC function similarly if we have the message the same but use two different keys we'll get two different tags and the concepts are similar to a hash function I think you may know from some data structures a hash function takes some large arbitrary size input and tries to map it to some unique small value and this is using a similar concept we take a large potentially large message and produce a unique tag as an output let's go back to that diagram and see why that's the if that property holds what an attacker can do so our requirements we say with our MAC function has the properties that let's try and summarize the properties required for our function the MAC function and there are different MAC functions but they need to have this property that is if we take the MAC of some message M1 with key K1 and get tag T1 and then modify the MAC with key K2 and message M1 we should get a different tag that's the required property two different keys input two different tags output similar if we modify the message same key sorry the first and the third K1, K1 M1, M2 two different tags as output that's what we require for the MAC function if it doesn't have those properties then it will not provide the security that we need it to do so we need to find a function that has those properties and there are different functions that do that we'll see some examples later and we'll see some more when we look at hash functions so the similarity is the hash functions the hash of two different values produces a different hash value so if these properties hold keys, different tag two different messages, different tag then what can an attacker do let's try an attack and there are several approaches so again A sending a message to B so A takes the message and calculates the tag and sends it to B but our attacker intercepts C is the attacker that was sent sorry we missed what is sent? M and concatenated with the tag T so we'll see what happens if we try and attack A has a message wants to send to B so they calculate the tag using the MAC function and the key shared between A and B they send the message and the tag to B but our attacker C intercepts and modifies something so they intercept and send to B but a modified value what do they send to B? let's see if they modify the message what can the attacker C try and do I know there are some malicious people in this classroom so try and give me an answer of what a malicious person would try to do to try and defeat the authentication system here what can we try and do? just try something we'll try something and then see if it works as an attack you had one before, what was it? modify T if we change T what happens? let's come back to that one let's say we modify the tag and we send M and some other tag T prime B follows the same steps always it takes the message received, calculates the MAC and compares to the tag so B calculates the MAC using KAB of M and then they compare that with the receive tag let's say that they get a value which is called T subscript C meaning the calculated T value just to keep them separate B receives the message thinks it's from A therefore uses key shared with A KAB calculates the MAC of that message and gets the calculated value TC and now they compare TC to T prime are they the same? so the process at B to verify the message the MAC of the message compare the tag calculated with the tag received we received T prime we calculated and got TC does TC equal T prime look how was T prime calculated T prime is the received value sorry T prime is the modified value TC was calculated using a different value so if it's a modified tag if T prime is not the same as T then T prime is not the same as TC TC is the same as T same input, same output MAC of KAB and M MAC of KAB and M T equals TC but if we say that C modified T to get T prime then T prime is not the same as T and therefore T prime is not the same as TC and if they're not equal something's gone wrong they must be equal to be authentic so in fact this is not a very good attack because it's not trying to achieve anything we'll try a better one in a moment that is B would detect that this message he received is not valid let's verify let's go back and try a different attack what else can the attacker do change both alright that's one correct we'll do that in a moment we'll do a simpler one first let's just change the message the message is increase C salary by sorry decrease Steve's salary by 10,000 baht the attacker's person I intercept and I change the message to increase my salary by 10,000 baht and I send that modified message on to B the accountant who updates the payroll so we modify the message to note it as M prime where M prime is different from M and keep the same tag so all I do is change the message use the same tag as before B goes through the steps to verify so B calculates the MAC using which key what key do I use if your B and you think the message came from A you use the key shared between A and B so we denote as key AB if I thought the message came from C I would use the key shared with C and the message I receive is M prime and we get a value let's call it T prime and now we compare T prime the calculated value with the received value do they match so B just always goes through these steps to verify MAC of the received message with the shared key compare it to the received tag go back to the properties of our MAC I've got it where I'll just go back for a bit these are the properties of the MAC function remember if we take one message and use two different keys we'll get two different tags if we take one so the MAC with key 1 and M1 produces one tag the MAC with the same key but a different message produces a different tag that's the requirement of our function similar if we use two different keys but the same message we'll get two different tags so always remember those properties of our function if the inputs are different then we'll get a different tag in a simple way now let's go back to what our attacker did T prime is the MAC KAB and M prime T the received value is the MAC of KAB and M where M prime is different from M because we modified the message that was the attack therefore the tags are different if the two messages are different even if the key is the same the tags will be different and therefore B detects that this is an attack and doesn't trust the message so by modifying the message the attack is unsuccessful because B verifies it they don't know what the correct message is it's just checking that it's authentic or not and in this case it's not the last attack modify the tag didn't help modifying the message didn't help let's try and change them both actually I'll leave that to you let's try a slightly different one just in the last few minutes let's do a masquerade attack C sends a message to B pretending to be A since C sends a message to B saying here's a message it comes from A B receives the message and verifies and to verify the same steps the MAC with a key of the message received and we get some let's say some calculated tag and then we compare the calculated value with the received value and if they're the same authentic if not don't trust it so this attack C is masquerading as A they send the message a tag when B receives the message and tries to verify they apply the MAC function on the message with some key what key what's the subscript B thinks the message came from A so this is the attack from C they're pretending to be A they don't know it came from C it's from A therefore if it comes from A to verify use the key that you shared with A the key that A and B share is KAB same as we had before we think it's from A therefore use the key that we shared with A and we get some tag and we compare it to the tag received do they match under what conditions would they match what is how was T calculated T was calculated from the message by C let's look at how C calculated the tag T was calculated as the MAC using a key of that message M as in the normal procedure C calculated a tag using the MAC function on the message and a key which key or correct which key didn't they use they didn't use KAB because they can't know KAB because KAB is shared between A and B no one else must know that otherwise it's not a secret so let's say they used I don't know KCB they cannot use KAB they use a different key T is the MAC of M with KCB TC is the MAC of M with KAB two different keys two different tags therefore not equal therefore we detect that something's gone wrong so in this case if C wants to masquerade as A to trick B they need to know the key shared between A and B but our assumption is for any secret value no one else can know it if it's a secret between A and B C cannot know the value if they do then they can defeat this system but if they do then we have other problems so C cannot pretend to be A because if they try to B would detect it because the tag would not match the expected value so if the tags don't match that's what we received if they match we trust it we haven't said anything about what is the MAC function other than stating some properties there are different algorithms that can be implemented here that provide the properties on Thursday we'll look at some different algorithms just as some examples but they're available and usually quite secure and the benefit is the entire message and in fact our MAC functions often can be faster than the encryption functions so performance is a benefit here the message is not confidential there's no aim to keep it secret so anyone can see the message it's just authentication what you can do is see what happens again put on your malicious user suit and try to pretend to be an attacker and see what you can modify and then see what happens at B when they try and verify and try all the combinations and you should then understand why it works why the properties are important and why the authentication is successful any questions to finish off today there's no other way to attack this find out I think we've covered all but one cases so we've covered the case of pretend to be some user and the previous ones covered the case of modify the tag, not successful modify just the message not successful the other one modify the message and recalculate the tag see if that's successful and I think that's the only combinations you can try so yes it's secure so long as our MAC function has those properties that we stated if it doesn't have those properties then we have a problem let's continue Thursday we'll look at summarise the properties and then we'll look at other forms for authentication