So I have to do it. So for now, I'll make it unlisted. And then I will modify it later and publish it. And co-host. So just a quick question. How does that work when someone wants to, so when people come in, they're all muted by default. So how does that work when someone wants to talk? They can unmute or they have to ask for it? They can unmute. I don't mind if they unmute. It doesn't hurt me.  And I'm about to make you host again. So you can see. Yeah, OK, there you go. So you're the host now.  Yeah, I'm going to let in also, Ben. I think I don't remember now because I don't have the controls anymore. But you should have a security icon and stuff like that. And there, you can do certain things like fiddle with people's mic and whatnot. Yeah, so by design, they can unmute themselves and start video. So we're going to let that going. Sounds good. Cool, all right. So in that case, I will leave you guys to it. Poke me on Discord if there's anything. I will also join the staff speaker's audio channel. And I'll be on that for the next little while. So I don't think anything should go wrong. I think we got through the major glitches this morning. So this should be OK. And then in approximately 20 minutes, I will publish the YouTube link so that people can follow along there. But don't don't even look at it. Like I will I will kill the chat there. It's meant to be read only. So it's just for anyone who's like, bad, I really wanted to do this and it was sold out. Yeah, I was going to try to ignore YouTube for sure. Because it just stresses me out. Yeah, yeah, yeah. Do do ignore it first place. I will pretend that I'm not. Yeah, all right. Cool. Well, I'm I actually wish I could do this workshop. I've been wanting to get something like this for ages at Norsak. I feel it's so it's so rare. You know, like people want to talk like deep like go deep into cryptography, like some very niche specific thing. And lately, it's usually cryptocurrency related for better or worse. Like there's lots of interesting stuff happening there for sure. But at the same time, just the use case of cryptocurrency is not necessarily exciting for everyone. But but actually, like, yeah, cryptography is not a panacea and there's a lot of ways to get it wrong. And there's a lot of ways to break it. Topic near to my heart, so have fun. And yeah, thanks. Thanks to both of you. Pay me if there's anything. Sure, you have the controls. Cheers. Fine. How can I let so I keep looking at so I have the list, the list of attendees here. Basically, as the command, I'm going to admit them. There's quite a few. I think it's 40. Yeah, yeah, at least. Well, I think it was capped before you. So there's more than that. And there's cheaters, which could be. Yeah, sounds like for you. Hackers be hacking.  Or is that just in my ear? Yes, yes, I am. Well, it's not very intrusive, but it's a beep. Oh, I'm on my microphone array. That's so now I should be on my headset, Mike. Oh, yeah, this the sound is actually better. Oh, good. So I was on like the laptop, Mike, and that's why you can hear the notifications. All right, this should be good. Yeah, it's very good. That's so good. So which what part of this are you going to stream exactly to YouTube? I think it's the old thing. The entire the entire thing. So when it starts to, I think they're going to stream the entire thing. I mean, like, which part of the stream are you streaming? Like, which? Do you know what I mean? Like, what? How do I ask the question? What frame? Which which portion of the X, Y coordinates of this is going on? On this, you know what? I have no idea. I can ask, I'm guessing the whole screen. I think it would. I would prefer it was just the slide deck because I don't really look amazing. Let me ask. Let me ask, I don't know if that's possible. I could just turn my camera off too. OK, asked. We'll see. OK, cool.  Yeah. Yeah, if that's the way we're going, that's probably what I'll do. No big deal. I'm not sure why anyone will want to look at me talking while going over crypto anyways. OK, yeah.  That's the way to do it. All right. We'll do. So you work in crypto in general? No, I do. I used to do security assurance at a company called Erdetto and a big part of what they do for kind of their their software protection technology is rooted in crypto. So I worked with a lot of people that are way better at crypto than I'll ever be and learned a lot from them. So when I got into truck hacking, the people that run Cybertruck wanted me to do this presentation because I was the most qualified amongst them to talk about crypto. So, yeah, that's that's where this comes from. It's it really is just an intro crypto one on one. And I'm not really a crypto expert. So that's pretty cool. So you OK if we let people in a little bit before everything starts so they can get set up and everything or you prefer to be at the two o'clock? Yeah, no, you can let them in a little early. That's not a problem. So like maybe in two or three minutes, I'm going to start letting people in. Yeah, that's good. Yeah. All right, I'm going to start letting people in. Okey-dokey. Hey, David, there's one user in Discord, JJ quadruple seven asking if they're supposed to receive a zoom invite. But yes, I'll talk to him. Thanks. Prum. OK, so I see one minute to go. I'm going to I'll just start with the deck right when my clock rolls over to the top of the hour. OK, so if you're here, you're here for how crypto gets broken by you, you're in the right place. Hopefully you can see my screen right now where I'll be showing the slides. There's another version of me in the Zoom meeting named also been where I'll be doing some screen shares during hands-on activities. Thanks for joining us. This is just a little about me. I do consulting work presently at the NFTA trying to secure heavy vehicles. I love tax trees. I love CTFs, maybe a little bit too much. I like to teach, so I'm glad to be here talking to you today. I've done this better development for about 10 years. I have a master's and I do stuff at SAE. I'm going to do a lot of talking today. I think you can read this slide. I'll stop talking about myself now. And now also that you've seen me and where I am here in my workshop, I think I'll just turn off my camera to avoid distractions and we'll just go straight into crypto. So thanks to many people, not the least of which are my friends, Sage Fault, Kenneth Salt and Dr. Jeremy Daly. This material was previously presented at the Cybertruck Challenge both 2018 and 2019, as well as at Hackfest 2020. So I've done it a few times now. I hope that means that it will go more smoothly than in the previous times. But you never know. So let's find out. The agenda is pretty dense. There's a lot of stuff that we're going to try to cover. We're going to generally speak, generally speaking, start with a review of material and then we'll have how to attack those kind of material that we reviewed. So for instance, we're going to look at building blocks and we'll talk about attacking those building blocks. I'm going to try to have hands on sessions mixed throughout the material. But once we move on into some of the more real world stuff, the hands on material becomes fewer and less often. So there will be a large gap in the middle without hands on with apologies. Yes, also, you are allowed to unmute at any time and interrupt me. I would I would much rather you interrupt me and I answer your question immediately so I don't lose you then to to go off the rails and have you lost by the middle of the presentation. So by all means, feel free to interrupt me. It's not a problem. Here we are. I'm also on the breaking crypto channel on the Norsak Discord. I'm watching that as is our moderator here, Mr. David Goulet. So we'll keep an eye on that. But if you ask questions there, I'll try to also answer them verbally if you wanted to type a question and I'll I'll just answer it while I'm talking. That's fine, too. And when we do hands on sessions, you're welcome to share your screen if you want help or any of the other methods we mentioned. OK, so the last thing on the agenda is that a lot of this material here, you know, I didn't invent by any means. I'm not a crypto expert. A lot of the material is here from Ross Anderson's really, really excellent book, Security Engineering, which is now recently in the third edition. And the second edition is free. So you really have no excuse not to get this book and read it if you are interested in creating or breaking security systems. Go and buy that book. OK. First up, crypto. I'm going to say crypto a lot. I never, ever mean cryptocurrency. I always mean cryptography to me. Crypto just means cryptography. And that's it. That's all I have to say about that. I do like this picture, though. It's kind of funny. So let's start with crypto building blocks. First up is encryption. We're going to use a little bit of nomenclature here.  It's because I want to arm you with a little bit of information that you might be able to use if you ever find yourself reading math papers or blogs that have math. So this is the pretty standard notation for doing encryption. The curly braces is the encryption operation. The K is a key. The message is the plain text and the cipher text is what you get. E. So encryption is an encoding ish, which can be reversed if you have the key. And that makes it different than just straight up encoding. You need the key. You need the cipher. And you need the cipher text. You need to know all those pieces of information. So some examples of encryption is AES and RSA, ECC and triple DES. Something that is not encryption, but you may find thrown around like it is is base 64. It is non encryption. So straight into a really quick hands on, make sure everybody's kind of got the juices flowing and is capable of doing things here in the in the workshop. I will give you some time now to decrypt those following quote unquote cipher texts. They're not cipher texts. If you're in the breaking crypto chat, you know, you want to just give me a thumbs up or something when you've you've done it and you feel confident or it's not too hard to decode these so you could do spoilers. I don't think that'll upset anybody. You know, the gist is and you can see this on the slide. They're not encrypted. These are base 64 encoded. You should be able to use any base 64 decoder. Yes, Cyber Chef is excellent red shell. Cyber Chef is great. You can use that. Thank you, Bloody Valentine. Yes, it is Sentinel. So I presented this last time at Hackfest 2020. And so it's themed. It's Hackfest 2020 themed. Yes, Eric, you got it. OK, I can see some people got their command lines or their cyber chefs cooking. That's excellent pause for a little bit. Just make sure and nobody has any questions or has encountered any problems. Yes, that's right.  We will take less than 10 minutes to do that. It seems like everybody is on top of it. I don't see anybody saying hang on a second or asking any questions. Let's see. Oh, I see people are using Zoom chat. I'm not really looking at Zoom chat, but here we go. So M Chevalier, if you download the PDF that we put in the workshop channel on the insect discord, you'll be able to copy and paste all the strings that are going to come up. And I highly recommend you go and get that PDF because there's going to be a lot of really long heck strings. I mean, maybe Kevin will keep copying and pasting them for you, though. And it won't be a problem. Thanks, David. So David, put the link to the PDF straight in our chat here so you can get it. All right. We'll move on looking in now the building block of hashes. OK, so specifically cryptographic hashes. There are other hashes used in programming, like, you know, for hash buckets and balancing and searches and things like that. But cryptographic hashes are specifically kind of not reversible. Right? That's the idea. Sometimes they're called one-way functions to highlight that you can't go the other way. Sometimes shortcut functions or trapdoor functions, I think also. And then you see some other a.k.a. is one-way compression, digest, random functions. The definition being that, you know, if you have a cryptographic hash function f, as you're given its output f of x, you can't find or guess or calculate x. Right? So specifically, if I gave you these heck strings here, the one starting with 39, the one starting with 21, you can't find what made them. And that's what a cryptographic hash function is supposed to be. Of course, practically, you can find what made those. Examples of some hash functions. SHA-1, SHA-256, Blake. An example of a hash function, which is not a cryptographic hash function, definitely not today, is MD-5. OK. OK. Next building block is the distinction between classic and modern cryptography. So classic crypto is mostly in the, you know, pre-20th century. And its key characteristic is that it deals with alphabets, both at their input and their output. A classic example of a classic cipher is the Caesar cipher, a shift cipher. OK. And that's kind of good to visualize with that picture there from Wikipedia. Other examples of classic crypto are substitution ciphers, polyalabetic, alphabetic, sorry, transposition. It is still encryption. The key in this case is the knowledge of that mapping. Right? So how many, how many letters are we shifting by? What is the table of substitutions? The relevance today, you're going to see them in CTFs and reverse engineering challenges for sure and puzzles, but classic crypto isn't relevant when it comes to security engineering. So modern crypto, as distinct from classic crypto, deals with numbers as its input and its output. The text is going to be treated as a number via some kind of encoding. You know, UTF-8 is an obvious encoding. There are alternatives. If you deal with mainframes, you might be dealing with an EBSDIC encoding. And this is some example of some text in some encoding. And, yeah, that is the difference between classic and modern crypto. Next building block is stream ciphers. So there is actually a theoretically perfect secure encryption scheme called the one-time pad. The key being that it's theoretical and it uses a random key stream and random being its unpredictable key stream and the length has to be equal to or greater than that of the message. And then the two get combined with some kind of a mixing operation which is equivalent to or assumed to be XOR. And the one-time pad is proven secure under all of those assumptions. Now, in practical terms, making sure you have a key that is completely unpredictable, making sure you have a key stream that's equal to or greater than the length of the message ends up being difficult. Historically though, the one-time pad has been used. A fun example is spies were reported to have pieces of silk that they would keep in their clothing with a pad on it. And when they were done using the pad to maintain synchronization with whoever was sending the messages, they would tear off the pad from the silk and burn it. And so long as they had pad left on the silk, they were capable of decrypting messages. Stream ciphers have been developed to approximate the one-time pad to get around the problem, mainly of pushing around key streams that are so long. Things that are long like that are hard to move and are hard to protect. Generally, they expand something short, a short key, into a longer pseudo-random key stream, and then they mix it with XOR. Examples of stream ciphers are RC4, Salsa20, and Fish. Something you should keep in mind when dealing with stream ciphers is that expansion from the short key material to the long stream usually requires some initial value. This is often pushed around and called an initialization vector. And it is not assumed that the IV has to be secret, but it is usually assumed the IVs have to be unique. Next building block to consider is block ciphers. So a different approach to dealing with the issue that comes up with stream ciphers. We have a pseudo-random sequence, and we're using XOR and a problem that can occur, which we're going to talk about as we go forward in this workshop, is anytime you're using XOR, you can't repeat your key material. Block ciphers use a different approach. They use fixed-length inputs. These are the blocks, and they will be combined with the previous outputs, hopefully not in the case of ECV, but that's sort of the degenerate case in different modes to create your cyber stream. So you can see two kind of examples of the block modes here, the first being electronic coloring book, which is a term I don't know if, Ange Albertini came up with it, but that's where I'm familiar with it from. It's a hilarious way to call electronic codebook, and you'll see why that's funny so later in the deck. And then cipher block chaining, which actually starts to mix the previous outputs of the block cipher mechanisms. And then there's other modes that aren't pictured here, but they go, you know, PCBC, OFB, CTR. GCM is the one you should pick up and use if you have a choice when you're doing designs. Next building block is the difference between symmetric and asymmetric cryptography with symmetric crypto systems. Any party that has the key is going to be capable of both encrypting and decrypting, plaintext or ciphertext. Right, so anything we've discussed so far is actually all symmetric cryptography. Asymmetric crypto is a new concept we haven't discussed yet. Asymmetric crypto, sometimes called public key cryptography, you get to create a pair of keys. One is known as a public key, the other known as a private key, which is communicating to you what you should do with them, how you should treat those keys. Public keys can be shared and you can think of them like an address, and private keys should be, well, get private. The asymmetric crypto leverages certain problems that are hard to solve in math. I think the key examples are prime factorization and discrete logarithms for RSA and ECC, respectively. And then they build operations on top of these problems that are easy to do in one way, hard to do in the other, so that any party with the public key can actually encrypt and verify as operations. But to decrypt or to sign, you need the private key. I'm going to talk more about signatures in a bit. You've probably encountered it. If you've looked at, you know, files on your hard drive, you might see begin RSA private key, and that's a good example of asymmetric cryptography. I think this one here is actually one of can of salts, private keys, if I remember correctly. I think I keep kicking this around to troll him. I should probably delete that at some point. Crypto building blocks summary. So I'm going to try at the end of every section to summarize what we talked about, and it was at this time that I'll also break to make sure that there are any questions that we could be answered, so I'll talk a little bit more. We talked about encryption. I gave you some notation that you might find when you're trying to do research to try to help you out. Encryption is going to protect your confidentiality, but it doesn't necessarily protect your integrity. We talked about cryptographic hashes, also known as one-way functions and other names. And remember, the idea of a cryptographic hash is if you have the output FX, you cannot get X. We talked about both classic and modern crypto. It's important to remember that classic crypto involves alphabets, rotations or remappings. And modern crypto is all about numbers, both input and output. We talked about stream ciphers. The key to any stream cipher is going to be XOR. You're going to be combining a sequence of key bits with a sequence of clear text bits or with cipher text bits to go the opposite direction. We talked about block ciphers that start with smaller key sequences but extend to larger clear text sequences through their block chaining modes. I hope I emphasize that not all block cipher modes are created equal. Key example being electronic coloring book. We talked about the difference between symmetric crypto and asymmetric crypto. In symmetric crypto, all parties share the same keys. In asymmetric crypto, only the party that has the private key can decrypt. So let's break for a couple of seconds here and I'll give you an opportunity to ask any questions. Again, feel free to unmute. Feel free to dump your questions into the Discord chat. I want to make sure that I don't lose anybody early on in the presentation or at any point. I see a couple of people typing in the chat. Thanks, KP. Okie dokie. Let's move on to some more stuff. So we're going to talk about attacking building blocks now. So attacking hashes, you can use Google. Seriously, you can just Google stuff and it will work a lot. Sometimes identifying what type of hash you actually have will be useful to you if Google doesn't give you anything right off the bat. You can usually tell what a hash is from its lengths. If you don't have all the hash lengths kind of table memorized in your head like my friend Sagefalt does, you can use this tool I recommend, you can use it as a roof and hash detector. It's pretty good. If Google doesn't turn up something for you, there are hash crack sites where you can submit hashes and pay a little bit of money and they will crack them for you. You can also use your GPUs if they're not already mining cryptocurrency or playing video games to crack hashes using Hashcat or John the Ripper as well. If you're going to go even further, the concept of a rainbow table is to pre-compute as much as possible of a hash's outputs from a sequence of known inputs and then to either in the middle or look at the direct output to match what you have. Yes, you got to do that's exactly what it is. Getting rainbow tables can be tricky, but if and when DEF CON comes back in person, you can go to the data duplication village and pick up rainbow tables if you bring a hard drive, which is fun. And then there's super cool things for attacking hashes that only super cool people do, not like me, and do hash length extension attacks. Some more work here from Ange Albertini, who is amazing. Starting on with a PDF, taking advantage of the fact that you can actually extend information into PDF and have it still rendered normally and then also then trying to extend the hashes with the hash length extension attacks to create two PDFs that have the same SHA-1 signature. So you see on the right there is the picture of the two PDFs and they both have the exact same SHA-1 signature. And for more details on this awesome stuff, you can check out Shattered IO. So a little more about attacking hashes because it's kind of easy to build those rainbow tables. It's very common for systems relying on hashes to use salts. What are salts? They're something that you prepend to the input or sometimes with a separator, sometimes without. The good news for us as attackers is that hash cap can actually find a salt for a given hash and input pair. So you can say, you know, here is a hash. Here's the thing that I'm pretty sure it's hashing from. What is the salt? And it can also find things given the salt as a parameter as well. So if you had some kind of system and you didn't know what the salt was but you could reasonably determine what one of the hashes was, it's a pretty reasonable assumption that the salt is going to be the same over the whole table if all the hashes came from the same system. So you could, from one of the entries, determine what that salt is and then for the rest of the entries, reuse the salt. That's how the kind of attack goes. When you are trying to break hashes, if Google isn't your friend and you don't have the money for the hash crack site, you're going to have to use hash cat or John the Ripper or some other cracking mechanism. You're really going to want to have some password lists and word lists. It is possible to brute force and hashes and by that we mean movie style hacking where you're changing every letter in the first position of the string and then you change every letter in the second position and so on and so on until you've exhausted all permutations. But doing so is usually prohibitively expensive and so password lists are much more useful. Password lists can be generated perhaps based on your target user's other passwords and then you're doing password reuse and that could be quite efficient. If you have nothing to go on and or you're in a CTF, the Rocky list is the most common and this attack is more generally known as a dictionary attack. Okay, next hands on. I've given you some hashes here. Most of them are pretty easy. One of them has a salt and you should be able to do this at this point. But as always, if you have questions, having issues, you can unmute, you can dump something in chat, whatever works for you. That's a top notch use of spoilers. Spoiler bar is KV nicely done. Okay, so Cameron on the zoom chat has the MD5 and the shot one. Yep, those are good. Excellent work. I did prepare a hash cat example here. Let's look at that. I'm not sure what this looks like. I am sharing my screen as also Ben. David, do I have to stop sharing the slideshow for people to be able to look at the other screen? Yeah, I think so you need to switch. Okay, right. So Bloody Valentine did solve the salted one. I can switch to also Ben if you want. Yeah, that would be great. Just switch over to also Ben. This is maybe how Bloody Valentine did it. So I created a file with the crackstation did. So I created a file reusing the unknown salted hash for a list of a whole bunch of words. These are all words that you have already cracked by Googling or other methods under the assumption that, you know, there's password reuse happening here. And one of these is the same word, but with an unknown salt. Yeah, it's a pretty, it's pretty short salt. Something just guessed it. And then you can actually ask hash cat to operate in a mode to discover the salt. And it usually works. Go like that. And I believe it's in the pot file. Probably, yeah. So there it is. So you can see the input text was Sentinel and the salt is now known as HF. So if you were trying to crack HackFest's passwords, now you would know that their salt is HF and you could do the rest. Unfortunately they didn't see my screen, David. I think so either people need to switch manually, but I don't think I can switch for everyone. So if people go on the top this view options, you can go on also then. Yeah, I don't think I can switch. Well, that's okay. Sorry about that to those in the workshop that didn't see it. I'll just, I'll make sure to stop sharing my slides next time. But it's what you would expect. It's a list of... It's a file that has all the... Every line is that, that 6C hashed one that's salted that doesn't just Google and then colon all the word lists repeated and then you just crack it using the hash cat. Search for the salt. M10. Does anybody want to wait a little longer on this hands-on challenge? I don't hear any objections. We'll just move on. Okey-dokey. Here we go. So what about attacking classic crypto? So remember classic crypto is the one that is based on alphabets and historically it was actually a frequency analysis that undid classic crypto. So in a language like English, there's a predictable occurrence, a frequency of letters in the language. So what you can do is look at your ciphertext and if it's classic crypto, certain letters will occur at a frequency that'll match the English language or whatever language you're dealing with. To do this though, you need to actually have a medium to large ciphertext to do that analysis. Today for attacking classic crypto, generally try a shift cipher. You know, start with rot 13 because that's often used just for the laws and then try a substitution cipher. And then if it's not one of those, you're just going to have to have fun. There's a lot of different options in classic crypto.  So we're going to go into another hands on here. I gave you a ciphertext. I'm telling you it's classic crypto and it's up to you to try to solve it. I can see now that my text effect is actually giving away some of the hints. Yeah. Yeah, rot 26 is at least two times better than rot 13. So what if you didn't know is rot 13?  Make some guesses. What are those letters? What's the most common letter here should be E. So try B, try A, try R. Some pretty good rot 13 humor in chat. Thanks everybody. You might just use a tool like Rumkin. Just capable of doing it pretty quick and you could just hit the down arrow on the little dropdown for the shift. See what pops up and you're bound to find out that it's shift 13. As everyone in chat seems to know now. There's no problem. And let's see.  Does excellent work. I see some typing. Decode. Oh yeah, the decode site is great. Excellent point. Someone's trying a cyber chef auto. Okay. Everyone's just tearing through the hands-ons. That's great. Lots of experience here. What about what about stream ciphers? Oh wait, doom is typing. I'll wait for you, doom. Got some more tool suggestions. J Crypt tool recommended by Silver Olin. Just making sure there's no questions. Don't want to lose anybody. So what about stream cipher attacks? So, pretty much always you'll attack these by a reuse key attack. Remember stream ciphers are all going to be at XOR. So you know a XOR B shown here is that a carrot B. Sometimes you'll see XOR is written as plus at a circle. But we use the carrot here. So if we know a XOR B. If we know a, we know B, we can actually get the other. So anytime a stream reuses keys, it's going to be a problem. You know, as the key example here, if I have E1, which is a XOR K. And I have E2, which is B XOR K. I can actually get a XOR B because you XOR E1 and E2 together. And the, that mixing property of XOR, because the bits always flip. Is such that the K's drop away and you're left with a XOR B. So this is a big deal if you know something about a or B. Are A and B some kind of a natural language? Are A and B different lengths? Do you control A? Do you control B? Or can you reasonably make some guesses about A or B that will reduce a search space for you? And you guessed it. We have another hands on. I've given you two cipher texts here. You know the stream ciphers because that's the section. And I say so. Can you get the key? And based on people's performance so far, I'm certain some can. So please do like Bloody Valentine and others use spoiler bars. People are going to be trying themselves. Don't spoiler for them. If you have any problems, any questions, please feel free to ask. You can unmute. You can drop and chat. The first hint, which it seems like you can see from the shadowing anyways is it's all about XOR. We know this. It's a stream cipher. And this was recommended previously. Cyber Chef. Great tool to play around with. So I gave you hex strings. So you're going to want to use like from the hex block in Cyber Chef. Next hint, which you may have been able to see from the shadow there is the key is 32 bits or four bytes. Right. You know, this is not a one-time pad. Key is shorter than the cipher text. So it'll be repeated. I think the next hint doesn't give too much away.  So I think either we've stumped the geniuses in chat who have torn through everything so far, or they're just being really polite and not posting their solutions either way. I think now is a good time. I'm going to stop sharing the slides to try to make share work better. Slides stopped. And I'm going to go over to also Ben. And we'll see if we can play around with this in. Cyber Chef together. So hopefully this time you can see my Cyber Chef window. I've set up. All right. Oh, excellent. Thank you. Yeah, so I set up a Cyber Chef recipe here. I think that's what they call them. And I have the input has the first safer text. Then I have an X or operation. And because I know I have a hex string, I have a from hex block. And then I like to do a hex dump at the end because then I can see, you know, the ASCII or UTF-8 decoding as well as the bytes. So if you remember, when we were talking about attacking these things, we're testing for reuse. So we're going to X or the two things together. And that gives this text string, which now we know is if things are being reused, the key has been removed. Right now, this is plain text a X word with plain text B. Let's look at another recipe. You'll recognize the input as a plain text a X or plain text B under the assumption that they both have the same key. It's not a bad assumption. So what should we try for the keys here? Well, I told you I was lazy. Not because I want you to think less of me, but because that's something that's pretty common. People are lazy. Let's try some of the strings that we've encountered already in the workshop. So we can try welcome. That's one of the strings. Nothing much happens there. We can try password. So things are changing, but doesn't seem giving us ASCII. Remember, we're dealing with a modern crypto system. So the numbers in numbers out. And if we're lucky, the numbers are going to be encoding text. We're looking for stuff we recognize. Let's try admin. It's always a safe bet. How about that? Nope. Using something so bloody Valentine's giving us some good tips about how they sold it. This is good. I like that a lot. I'll go on that a second. So yeah, eventually we would come down to using a string that was correct or you could brute force. We'll talk about that in a second. So you'll notice that if we try Sentinel E, we get HF 2020. There you go. So that doesn't tell us that the key is Sentinel. That tells us that one of the clear text was Sentinel. And if you wanted the key, you would have to XOR it again. But we know what the clear text are. See how if we use HF 2020, we get Sentinel in the output. Because what we're dealing with here is HF 2020 XOR with Sentinel.  So bloody Valentine figured out that Sentinel was the first clear text for brute force. And then XOR the second string with the key. Which I think is pretty similar to what we're doing here. There is a brute force plugin in Cybershift. You might also just use some script that you put together. And it should be able to shoot things out if you have a good test for when you're in the UTF-8 space. It's a good job. Does anyone have any questions? Should be sharing the slide deck again here. If you don't see any questions, I'd like to assume that means that everyone's good. But there's no harm in going back over it if something wasn't clear. Don't worry about it. We can easily do that. Okey-dokey, moving on. Okay, what about block cipher attacks? So we're going to get into that valley of the material now where the kind of attacks that we'll discuss are not practical for hands-on. So let's talk about theoretical attacks and try to give you a framework to think about them. Maybe it helps you research something that you're going to develop or finding some cutting edge papers that will help you crack some crypto in the future. If you're going to be talking about block cipher attacks, there might be a goal of forgery involved. So you would like to actually create a cipher text yourself. Or the goal may in fact be trying to figure out what the key was that created the cipher text so called key recovery attacks. These attacks also occur given certain assumptions and the models all have pretty common names. So maybe these will help you in your searching as well. There are known plain text attacks where the attacker is given a set of pairs of clear text and cipher text. There are chosen plain text attacks where attackers are able to query for clear text and receive cipher texts. There are chosen cipher text attacks where attackers have the ability to query for cipher texts and receive clear text. There are chosen plain text either way. And with those ones, they can query either and get the other. So it's a combined model. And then there's related key attacks. So the attacker may be able to query with a key related to the specified key. So k plus one or kx or something like that. Like the object dereference attacks that you hear about a lot in APIs where the key itself might be guessable or inferred from previous values. More on block cipher attacks. We're dealing with blocks because block ciphers might not align with your input data. There may be a padding involved which goes in between the plain text and the block cipher operation and how that padding is done has to actually operate correctly with respect to the block cipher to avoid leaking information. So there are whole, whole suites of padding oracle attacks that give up information because of incorrect interactions between the two. The attacker in in a padding oracle attack is going to supply cipher text and can detect incorrect padding error conditions. And then being able to detect these air conditions lets them infer information and in these cryptographic attacks anytime that an attacker can learn something true or false. By asking a question they call these oracles the oracle can tell the attacker true false and the padding whether it introduces an error or not becomes an oracle for them. And in reusing the ability to try different paddings and get answers from the oracle. They can sometimes recover cipher text or clear text and sometimes recover keys and the padding oracle attacks have turned out to be surprisingly common. Mostly showing up in TLS, SSL, depending on what it was called at the time. And then things get even more fun. So in the general category of analyzing, you know, cryptography for flaws. There's two kind of large groups. The first being linear crypt analysis and the second being differential crypt analysis. Linear crypt analysis is all about solving for linear relationships and, you know, the math here looks a lot like correlations or linear algebra. So the kind of stuff that you would find in machine learning. In fact, it's all about fractional likelihoods of bits. So you can use the likelihoods to sometimes predict what cipher text would be from clear text or vice versa. And ideally, and for correct cryptography, it would be designed to resist these attacks, things like, you know, good crypto like AES just is resistant to linear crypt analysis. The mixing or the diffusion stops that. Then there's a larger category for differential crypt analysis, which is all about solving for sensitivity relationships. Meaning, if a bit in a given string changes, what is that change of bits impact on the output? Again, this is all for fractional likelihoods. And the high likelihoods can be used to guide attacks. Modern crypto is once again resistant to this. But it does become relevant in things like side channel attacks, where you have some kind of observation of timing or power from the calculation. Other cool stuff. Maybe this helps you in your searching as well. There are things called slide attacks and XSL attacks. There's the impossible differential in the boomerang. Cool names for cool stuff. Definitely more research for you if you're interested. All right, reality check. I talked about a lot of stuff. Some of it pretty esoteric towards the end there. And pretty much by the time we hit the block ciphers, cipher attacks, it was becoming impractical. For correct crypto, it's hard to break. I think you've probably heard people say this, that crypto is hard. Meaning, when you encounter correct cryptography, you're probably not going to crack it or break it. But for incorrect cryptography, you might have a chance. So, you know, test, is it XOR? Stream ciphers are based on XOR. The cryptography you're dealing with may in fact also be based on XOR. Are there repetitions or data patterns in the cipher text? We saw that ECB is sometimes called Electrode coloring book, and I hope to show you that picture soon, so why? But the repetitions of data patterns might let you learn something regardless of whether you can actually break the cipher text or not. And of course, if you can figure out what the name of it is, Google it, you might find a POC. But remember, it's not impossible. You have correct crypto building blocks. The protocols that use these building blocks to put together the communication or the operation for securing the info or the commands are where things go wrong. And so you might have a chance breaking the protocol. We're going to talk about that next. And also never forget software exploitation inside channel, which are outside of the model. So it could be useful to use an attacker just looking ahead here. I think it might be a good time. We're hitting an hour. Let's take, let's do this hands on challenge and combine it with a bio break. So five minute bio break followed by a 10 minute challenge, however you want to divide that up. And we'll we'll be back to go over the solution to this at 15 minutes after three. Hello, back again. Hope you can hear me. If anyone has any questions, again, feel free to unmute, ask them or put your questions in chat. That's good to move on from this challenge in about four minutes. I'll keep revealing some hints. Okay, so hopefully everyone is back. If you have any questions, please drop them here and chat or unmute. I think we're pretty much ready to move on otherwise. So you can see these are from crack me's crack me is like a reverse engineering challenge where you want to figure out what password to send into an executable. The string shows up in both from the crack me, which should tell you something about what kind of encryption we're dealing with. You have two hints here, and then you have the hexadecimal version of the encoding of the octothorpe and of the dollar sign there. So that should be all you need. Bloody Valentine sold it in chat. I'm sure others have to. Does anyone have any questions. Okey dokey. So yeah, these are actually the invalid password and password okay strings from that crack me. And it's just a shift cipher, but because it's in a crack me. It's actually modern crypto operating on the numbers. So the symbols get shifted according to the year they're asking representation as well as the letters to excuse me. Hi, I have a question. Yes. How about the hashtag. And the dollar sign. What is an answer here. So the hashtag is actually hex 35. Right and the dollar sign is hex 36 in the asking encoding. And you'll see they show up in the in the two strings. Okay. So the hint is telling you these two bullets and the hints and trying to tell you that. The hashtag decodes the space after three decrypts the space. And the dollar sign decrypts to exclamation mark. To show you that it's actually a shift by three. But a shift by three in the ASCII space, not in the letters. Does that help. You're welcome. Happy to help. I'm glad there was a question. I'm glad we didn't didn't lose you. So we'll move on a bit. Other attacks on block ciphers. One thing I mentioned before the break is you can actually look at cipher text structure. And sometimes you can infer what's going on from the structure, particularly if the block cipher mode is broken like ECB is. This is the picture that explains pretty well why you might call ECB electronic coloring book. So the thing on the right is actually an AS ECB encoded picture of the little tucks that you see in the brackets on the left. And you can still see the tucks because the size of AS ECB is the AS size, which is 16 bytes. So 16 bytes get repeated. And it doesn't matter what the key is for white or transparent. It's the exact same output of AS ECB for each one of the 16 bytes where the input was all transparent and same for his belly and for his flippers and stuff. So you can still see tucks because he's represented in the structure that's in the output of the cipher text. Yeah. And an important point is that if you're dealing with files that you know are sparse, then the contents of the file might actually be mostly zeros. So that's a reasonable guess about what the input might be. If you're dealing with flash, then the contents is probably all f's, which is a good guess of what the input may be. There are good ways, good tools to visualize, like binaries you're given that you think might be cipher text. VIX is a really fun one. VLEASE is a lot easier to install and set up and gives you mostly the same features these days. Binviz.io has some great ways to visualize. Raid air is cool. And I tried out Hobbits recently, which works a lot like VLEASE. And it's pretty good too. So attacking building blocks doesn't stop there. Software exploitation is definitely relevant. If you can gain control of the software that does the encryption or decryption operation, and it's symmetric encryption that's in play, then you have access to the key material that lets you do either. If you're dealing with an asymmetric system, then software compromise of a component that only deals with the public key might not give you the privilege that you're after. When you have access to memory, there's actually lots of tools that can scour memory for keys, such as a ES key find, Raider 2, and Volatility. And of course, reverse engineering the code can actually show you where in memory the key material or other parameters may be. In addition to exploitation, there might just be simple info leak vulnerabilities that give you key material or pieces of key material, the most famous being Heartbleed, which did potentially or maybe actually leak private keys of the servers that were doing the TLS communications, hosting the open SSL implementations that have Heartbleed vulnerability. So let's talk a bit about entropy visualization, which can be pretty useful for identifying ciphertext, maybe even saying something about them when you don't know much. First, what is entropy? So we're talking about entropy in the sense of Shannon information theory entropy, not the entropy of the universe getting more chaotic. It's actually an information density metric. And it turns out due to an important result from Shannon that the entropy is actually maximized when the likelihood of one and zero are equal. So a perfectly random coin flip is actually the most high highest entropy source, right, and any any bias for a bit to be more likely zero or more likely one is a loss of entropy. So completely random is actually the highest entropy. So there are actually estimators of entropy of a bit sequence. And, you know, without getting too much into statistics, the estimators of the entropy are not actually the entropy. They have their own bias and resolutions, but there are estimators. An estimate of entropy will approach one for a perfectly random number sequence. So if you run an entropy estimate on a file, and it's pretty much one as close to one as you've ever seen or are used to with that estimator, then that's most likely correct crypto crypto. If it's somewhere below the highest value that estimator gives you, then it's probably compressed data. Compressed data doesn't quite hit the same level of entropy as encrypted data. And then for other structured data, you can imagine like things like images, text files, anything where the probability of a one or zero isn't 50 50, you're going to get estimated entropy that's not as high as either compressed or encrypted data. Sorry, no unmasked will interrupt from the kids. All right. So when estimating entropy for large files, you're typically going to do that by breaking up the estimates of entropy into chunks or blocks, and then you're going to want to visualize them. If you have such a visualization, you can identify sort of the location of encrypted content. You can identify the location of compressed content. So it's good to have for plots. Here's three examples of different methods of encrypting tucks. The penguin. So the first one is tux to penguin, and we're looking at an entropy plot. Sorry. Another nonmask will interrupt. All right. So we have three images. The first, yeah, hashtag kids exactly. The first is tux unencrypted. You're looking at a bin vis.io entropy rendering. We're not looking at the Hilbert space curve version of that rendering. It's just scanned. So think of that as like every 1024 bytes or so lined up like a stack. And then the color of those bands, those scan lines in the image are the little entropy estimates per block of the file. When you compare that to something like the ASECB encrypted tux, you can see dark bands. I mean, I hope Zoom is able to reproduce the dynamic range enough to see the difference. Looks like it should. And the ASECB looks much more like solid magenta as compared to the banding in the uncompressed file. ASCBC, on the other hand, if you were to look at the point plot, you don't get to see the structure of tux anymore, because it doesn't have the property of producing the same cipher text given the same clear text over and over again on the block. Remember, CBC is chaining the output of a previous block into the current block so that state evolves as it goes over the file. And that's why the picture on the right for tux looks much more like noise than the picture in the middle, which looks like the coloring book. But an important thing to note here is that ASECB's entropy visualization is pretty much the same as ASCBC's entropy visualization. Question, oh yes, the yellow lines in the bottom. That's Mastayoshi, just about to get to that. Oh, the animation does not quite work well. I will show you. Hopefully you can still see the presentation PowerPoint window. So these things right there that are supposed to animate in, but they don't. They're actually binwalk entropy plots. So if you have the binwalk tool installed, you can do a dash capital E on a file. And if you have the correct matplotlib Python dependency, it'll create these plots for you. And side by side, you can definitely tell that the entropy of the tux is slightly lower than the entropy at ASECB. I don't think I could tell the difference between the ECB and the CBC, but there may be one for viewers that are smarter than me. But the binwalk entropy plot is something you could do if you don't have access to binbizio, which is an online service. So that's an alternative for you. Okay, so we're into another hands-on challenge. I created a collection of files here in this Google Drive. One of them is a compressed file. One of them is an ECB mode encrypted file. And one of them is a file encrypted using a mode that isn't broken like ECB. Using these tools and others, you should be able to identify A, B, and C. The hint there that is masked with the troll face next to it is that I did corrupt headers, so you can't just use file. So sorry, not sorry. We'll spend some time on this. I hopefully can download that zip file. If you have any questions, feel free to unmute and ask them or put them in chat. Oh, is that link dead now?  I will fix that. Seems it's fine, Ben. It was a typo. Okay, good. All right. I was trying to figure out where that was going wrong. Thank you. Excellent. Okay. Well, I hope everyone's having fun playing around with... Playing around with entropy visualizers. Those are fun tools. My personal fave is using Radare's P equals E output, which has a nice vertical output in the terminal. But there's lots of different options. So we'll move on unless there's some questions. Right. So we talked at length about attacking building blocks. It's been quite a while now. Let's do a review. Again, I'm happy to take questions on the section right after this slide. We talked about hash attacks, a whole bunch of different kinds. Some are collisions, some are pre-image. Remember, using Google, we'll probably get you what you're after. All the other practical attacks use Hashcat. For classic crypto, you're dealing with letters. So frequency analysis is what you're going to try first, and then use things like cryptogram tools, maybe QuipQuip, or some of the other people that posted for stream ciphers. Basically, just try exploring things together and then try some guesses about plain text, see if things make sense. For block ciphers, this is getting impractical. Remember, you might have better luck looking at the output of block ciphers, looking for structure, but for block ciphers, what you need to know is what to search for. So there's different classes of attacks, which are models. And if you're lucky, you'll find someone's written something up for you. Remember, goals for block cipher attacks, you might be trying to do forgery, or you might be trying to do key recovery. There's large families of different attacks on crypto, linear cryptanalysis, differential cryptanalysis. Hopefully some of this helps you in your Googling. ECB is a very clearly broken block cipher look for structure and the output recognize patterns. And don't forget about software exploitation. The keys you need might be in memory in a process you can control. In general, correctly implemented crypto doesn't get broken, but the protocols that use it do. And we talked about cryptogram tools. There's a bunch of chat that are personal faves of different people. Like the Rumkin tools and then some visualization tools, which I hope you had a chance to kick the tires on. So we're going to move on to protocols. Just a quick pause. Does anyone have any questions about what we did with attacks on building blocks? So there's going to be fewer hands on from here on out. And I'm going to be doing a lot of talking because we have a lot to cover. So protocols are the rules that govern communication between parties. They assemble the different building blocks we've talked about. They, they instruct who has to do what and what parties perform them, et cetera, et cetera. Usually you'll see them in specifications. Here's an example of a simple protocol, a simple authentication. In this protocol, we have a source and a target. The source wants to be authenticated by the target and the target gets to decide if the source is authentic. The source is going to send to the target. It's identifier. We'll call it T plus an encrypted concatenation of T and a nonce. So we haven't talked about nonces yet. It's a contraction of the term number used once and it's very important in all protocols that the number is only used once. So the source is sending to the target T and it's encrypted concatenation of T and a nonce N along with a key here shown as KT. KT could be specific to that ID and it has to also be known to the target. So we're using the nomenclature, the notation that we started out with beginning of the deck. The target actually looks up that encryption key KT for the ID T and can then decrypt that encrypted concatenation of T and concatenation of N. Checks of the nonce hasn't been seen before and if it decrypts to what's expected, it says, yep, you are authentic. This is, for example, the protocol used in key fobs and garage door openers, the very old kind where the source is the fob and the target is the car or the garage door. Here's another protocol for you. Message authentication codes. So for a message, create a value that can enable the message to be verified by any party that has the shared key. There's examples of this being CVC Mac, which builds a message authentication code using CVC chaining of a block cipher. There's also a C Mac, which is using a block cipher as well. H Mac, which is using a hash. So examples specifically of what algorithms those get built up with is like CVC Mac a S 128 or H Mac Shaw one, right? So the the actual message authentication protocol will include what are the building blocks it's using. The parties that are receiving these messages. They don't verify against the key they have to discard. That's how the protocol works or maybe if you're doing authenticity, you might have some other error checking. It's important to note that these are symmetric. In most of these cases, the C Mac is anyways. And that means that what you use to create a message authentication code is the same key that you use to verify the message authentication code. Sometimes these are called message integrity codes because authenticity and integrity are kind of synonyms in security. They're also called protected check sums sometimes often confused with max is a message digest where you just take the message and push it through a hash function or a cryptographic hash function and call it a and that's not actually a message authentication code because it can be forged another protocol for you digital signatures. So these use asymmetric cryptography. The signing party has to have a private key to create a signature and the verifying party only needs the public key to verify that signature. Examples being DSA and ECDSA. The ECDSA is for elliptic curve. Let's consider a simple RSA signing method in some detail. So you might want to send a message M along with a signature which will show as the curly braces of H of M. And if you want to verify that, you're going to need to decrypt that encrypted H of M and assert that it's actually equal to H of M or H is a known cryptographic hash function and K is the private key. So in both a Mac and signatures, the parties receiving the messages that don't verify are supposed to discard where there might be some other error handling. How those public keys get distributed and how messages are discarded is additional protocol details. And this is the next layer and can be where things go wrong. For example, some protocols actually just send the public key prepended or appended to the message. So that public key goes along with the encryption. Here's another protocol for you challenge response. So the source wants to be authenticated by the target just like we saw before in simple authentication. The source is going to receive a nonce as a challenge. It takes that challenge and transforms it by some means into a response. So the target has some function and the source has a matching function. You'll see that in the blocks here. We got crypto over on the left in that function and then over here on the right we have crypto but in orange. Hopefully I got one chuckle from that. An ideal challenge response would make it impractical for an attacker to guess the secret by observing the traffic of multiple of these exchanges. If an attacker can actually see the challenge response then that falls into the category of what we describe before as a known plaintext attack because they can see the ciphertext and the clear text for that orange crypto. All right, protocol summary. So we covered a bunch pretty quickly. Digital signatures, message authentication codes, what is a nonce, what's simple authentication and what is a challenge response style authentication. Do we have any questions on the protocols section? Okey dokey. Let's talk about some attacks on protocols. So generally speaking, you try to attack a protocol. You're probably reading a specification and so the technique really generalizes to attacking any specification. Anywhere that the spec says shall or should see what happens when it don't. For simple authentication, try to assume that the nonce, because simple authentication actually assumes the nonce has never been seen before because it's a number used once. Do you know if the nonce is random or is a counter? In the case where it's actually random, the receiving end being the target has to know that it hasn't been seen before. So does it check? Does it have, does that kind of memory? Try sending it again. So if it does have memory, how much memory does it have? How many nonces does it store? Does it only store the previous one? In which case you can send plus one and that has a name called the valet attack. If the nonce is a counter, how does the counter get resynchronized between the source and the target? Try sending counter guesses. Try also looking at how the systems do their resynchronization out of band. And that's an example of how sort of something outside the spec can ruin the spec, right? There are examples of key fob attacks that are based entirely on just getting the counters to resynchronize. For simple authentication, because it assumes that that key KT is actually associated with an IDT, are there any other T that could associate with KT? Try sending other targets to try to get a collision. So maybe the target is using a very weak hashing function, something that has collisions. And so you can find other IDs that will collide. Attacks on Mac. Remember a digest is not actually a Mac, but because you'll often find them being given to you as a message authentication code, it's worth talking about digest attacks. You will know the input, right? Because you're going to be given a pair of a digest and a message. So you need to identify the algorithm. The length is going to usually give it away, but we also talked about this tool. And you may also need to identify the salt. We talked with a technique for that. For things that aren't broken like digest, hash cat still has lots of different ways to crack keys or salts given an H Mac and a message pair. So for H Macs, hash cat is your friend. And then not to be underestimated for attacking Mac software exploitation is still relevant. Because for example, in the case of a C Mac, we're talking about symmetric crypto. So if you can take control of a party that's capable of creating message authentication codes or verifying them, that piece of software has enough privilege to access the keys that can do either creation or verification, right? So you might take control of a target that's doing verify, but that software that's doing the verify has the key material in it to also do creation forgery. Let's talk about attacks on digital signatures. So recall the RSA signature example, where we're sending the message M concatenated with the signature being the encryption of H of M. The problem is always agreeing on the public key for the private key. Maybe you send the public key along with it, which is a common kind of solution to the problem. But if that's the case, then the attack that becomes possible is to substitute the blue K and the pink K for your own pair of A and A. So you send a public key of your own in place of their public key and you send a encryption of the message, which you knew, against your own private key. And then you've created something that it now will validate on the other end. So watch out for that broken protocol being sending the public key happens sometimes. And you can generalize that also to try to find ways where you can substitute the expected public key. Maybe that public key is stored in flash and you control the flash. That's something that happens in broken, verified situations. So an attack on challenge response, and this is sort of a generalized attack on challenge response, is the middle person attack, sometimes seen as the MITM attack. It goes by actually interposing some system or an actor in between the source and the target. And the system that's interposing between the two of them can actually tamper with contents or reorder or change timing. It's a good framework for attacks on challenge response protocols, and it's definitely applicable in TLS and SSL, where you can interpose, maybe you have proxy or you're using art poisoning to create some kind of a man in the machine in the middle framework. It can also be effectively achieved without actually physically being in place. So on CAN networks, you can selectively deny messages by corrupting bits in the checksum field and then sending the frame you want to substitute shortly thereafter, and that can look a lot like you're interposing, even though you're just sitting on the same bus. All right, section summary of attacks on protocols. We talked about a whole bunch pretty quickly. For simple authentication, there's key collisions, key extraction, replay, valet, bad counter, resync. For message authentication codes, try digest first because it might just be a digest, and that's not a Mac, and then it's trivially broken. And then for HMAX, you can use hashcap. For digital signature attacks, maybe you can substitute that pub key. How is that being transmitted? How is it being looked up? Where is it being stored? And for challenge response attacks, in general, you want to look at middle-person attacks, and we'll talk about that some more in the later sections. Do we have any questions on the attacks on protocol section? Okay, cool stuff. Moving on, let's talk about one protocol in particular, WPA2. So this stands for Wi-Fi Protected Access 2. It's a Wi-Fi confidentiality measure, and it replaced WEP. It's often seen as... I was looking at a ding here. It's often seen using the pre-shared key mechanism, the personal version. Each client gets its own session key, but how you get your session key is based on the pre-shared key. And there's a variant called Enterprise, but with Enterprise, every client has its own individualized keys. Let's talk about WPA2 personal. You will recognize WPA2 personal as a challenge response protocol. So the access point is going to send a nonce to the client, the supplicant in their spec. The supplicant sends back a nonce and a Mac, then a global key, and a Mac is sent back to the client, then there's an act. And I'm grossly oversimplifying this for the purposes of talking about an attack, but it's at the point that the client receives the global key and the Mac that the client actually installs the session key. So there is a Mac. It's implemented as an HMac, which is sent by the supplicant and derived from that pre-shared key, which means hash attacks to reverse this are possible. If you have multiple observations of the nonce and the Mac, there are advantages. So some people end up doing a lot of de-off to get multiple of these observations. Hashcat can do the cracking, but not the de-off, so people use things like AerocrackNG. I can do both. There's actually a key reuse vulnerability in some client software that was dubbed Crack, and there's a website for the Crack attack. But it's interesting to look at how that works for a challenge response. So when the key is installed, the specification says that the client has to actually reset its communication counters so the attack goes that by actually replaying that key installation, the yellow arrow, you can tell the client to install whichever key you decide you want. And in fact, some of those clients were implemented in a way that would even let them accept a null key, which would be very easy to figure out the traffic thereafter. And I bring this up because it's fun to remember that WPA2 was actually formally proven to be secure by, you know, proof assistant analysis of the spec. But these systems that are, you know, formally verified, the assurance that's granted is only as strong as the specification is, right? So even though it was all proven to be formally secure, what was kind of missing was a formal proof that was validating that the key would only be installed once and only once. So I use this one to highlight to people that formally proven isn't necessarily 100% secure. All right, this is a hands-on one minute that I'm not going to make you do. It's just a joke. We kind of do this in Cybertruck. We say, hey, go crack all the Wi-Fi. But don't really do it because we're using it. Just move on from that. So in summary, WPA2 passwords can be cracked via the hashes that are exposed in the handshake. The WPA2 keys can even be reinstalled. And sometimes what you can install is even a null key, which is interesting. Now, all these attacks actually require clients are connected because it's the observation of the handshakes that gets you the key material cracking. Are there any questions on the WPA2 protocol section? Let's talk about TLS and SSL, which is the S in HTTPS. I know that you're not supposed to call it SSL anymore and it's only and always TLS. But when you're Googling things or looking up documentation or talking to people about fixing stuff, it may just be easier to see them as an SSL. It does provide both confidentiality and authentication of the endpoints. Typically it's a client that authenticates a server but TLS does allow for mutual authentication where clients are also authenticated by the server and we're not going to cover that. So the model we're thinking about is the node here on the network on the left is connecting to the cloud over here on the right and there's a decision point by the client marked by that diamond with a question mark in it. And the client connects, does some things and eventually receives a certificate and decides whether the server is authentic based on that certificate. So certificates you say what are those? What are certificates? Well they're chains and digital signatures. This is asymmetric cryptography and we talked about what signatures are. So remember that only the owner of a private part of a public key pair can actually decrypt things that were encrypted and create signatures that are verifiable. The verifiability is by anybody with the public key. So it's certificates leverage this asymmetric nature of crypto. The signature can be signed, can have signatures in it of material and then only the person or actor that controls the private material can create that signature but anybody that sees their public part can verify that it was them that signed it. So here's a picture from Wikipedia of chain of certificates. They'll often be things in the middle, maybe even more layers than just one. But ultimately at the top there's a root certificate so called because it contains a self there's the end of the chain but the root certificate actually signs the intermediaries and the intermediary certificate signs the end entity and the chain maybe longer than that. So this is how clients are supposed to authenticate servers. They're supposed to check does the owner's public key match the issuer certificate and does the intermediate certificate's owner's public key match the issuer certificate and upwards on the chain validating all of those and then also validating at the end that the root certificate is found in some short list of trusted root certificate authorities and it's commonly the list is commonly called a trust store so ultimately it checks that the root CAs in the trust store but it has to do all of those steps to validate the chain. In practice there's a whole bunch of ways that the implementation of those checks goes wrong and this is just a categorization. I don't know if there's more official names for these so I gave them the very uninteresting names of type 1 through type 6 so for a type 1 implementation it's broken and it just trusts anything it doesn't care if there's SSL or GLS it just continues so HTTP URLs will work for type 2 this is an implementation that will trust any certificate that's valid for type 3 this is an implementation that will trust anything that has a root CA that's in the operating systems trust store and then we get into types 4, 5 and 6 these are certificate pinning implementations which is a mitigation against people doing middle person attacks on the SSL and the TLS traffic so for these types you're actually implementing your own trust store or a limited list of CA's in the trust store or you're pinning against a specific and entity certificate all of the middle person proxies out there like ZAP or SSL strip they're going to work out of the box on type 1 and type 2 because type 1 doesn't care about SSL to begin with and type 2 only looks for the fact that there's some valid certificate not that it is one in the trust store or one that has a valid chain to a predefined list so that's in context this is the way I kind of think about the implementations so I've said a lot about middle person attacks I don't think I've told you what they are in the case of SSL and TLS there's a lot of examples out there I like the MITM proxy tool which is a console application written by Aldo Cortesi there's also burp and ZAP the Martian toolkit is really interesting for working with mobile phones there's also non-HATB based middle person proxies MITF it's a framework it's pretty useful and then of course Etercap which is superseded by Bettercap are really great then there's the old and still useful SSL split some of them require that you actually set up like a proxy so you have the software configured to talk to that piece of software directly but some can also work just by being plugged into the same LAN segment so MITMF or Bettercap is an example of this where you can poison all the hosts in the LAN segment and they will redirect the traffic to your gateway your proxy without any reconfiguration of that software that you're attacking so let's talk about certificate substitution attacks which is how most of these middle person attack proxies work this attack will work on type 2 type 1 in this attack your proxy is actually going to be creating two TLS connections there's one that's upstream and there's one that's downstream the client connection to the server is normal there's nothing really to see there on the upstream side on the downstream side what's served to the client that middle person proxy actually supplies some other certificate it doesn't really matter and a lot of the tools that you'll download and install they'll just automatically generate a certificate to serve it and if you're dealing with a type 2 client this is a client that is just checking that there's some cert not that it's anything it was expecting it'll be happy because it saw a cert the red certificate being served and then it carries on and this works surprisingly this works a surprising number of times so it's always worth testing then for clients that are properly validating the certificate chain that they're being served you want to think about trustor attacks so do you have control over how to add a root certificate authority into the trustor for example if it's your android device and you have UI access you can add something to the trustor can you or can you use a compromise root certificate actually going back to the adding to the trustor that's relevant for researchers that are trying to get into the traffic of mobile apps but it's also something that nefarious types can trick users of for example coffee shops to do you could say hey install this thing for faster internet access most people would happily click and install something for faster internet access so it is also something you might want to consider in your threat model not just for mobile or sharing then of course those trustors that get distributed with browsers and mobile apps there have been cases in the past where they're shipping they're shipping root certificate authorities that have been compromised but that's few and far between and would have to be timed time properly to make use of that so what about types 4 to 5 so remember these are implementations that are doing certificate pinning how are we going to attack them well remotely if that's your only connection to these things is over the network you're going to have to be dealing with software exploitation to find the location of the code that is doing the check and do something about bypassing it or disabling it if you do have like if this is your device that you're dealing with so let's think about an android phone and you're trying to look at a mobile app that's doing certificate pinning to protect its traffic then having super user privileges might be enough to replace an expected pub key in the code or in some other resources of the app you can patch it or runtime hooking so for some time now there's been a universal android SSL pinning bypass using Frida which is a great way to start looking inside the guts of apps that are trying to protect their traffic and then for type 6 this is a type we talked about maybe not enough, maybe too briefly it's an implementation that actually includes runtime integrity checking so things like the hooking with Frida and the patching of a pub key resources wouldn't work so what about some other attacks there's a whole suite of problems over the years with SSL and TLS they have cool names like Drown and Poodle, Logjam some of them are practical where there's just POCs available some of them ended up being very powerful like Hartpleed basically use your SSL TLS scanners like the one from Qualys and verify that you don't have any vulnerabilities or if you're attacking make use of the ones you do find there was a really interesting talk that actually used differential crypt analysis so remember we introduced the difference between differential and linear crypt analysis and it did so by just using the passive differential perturbation of bit flips on the network so if you look at traffic like at a very large scale that small probability of a bit flip during an operation turns into a practical number of instances you can observe and Marco Rotizzi and his colleagues presented this a blackout a few years ago they were able to recover private keys by using differential crypt analysis attacks only on those bit flips which is just some cool stuff I don't think it's practical for any of our testing but it's fun to think about alright so section summary on TLS and SSL don't say SSL anymore say TLS it gives you confidentiality and authenticity the authentication is actually established with a certificate chain verification and you only get that if the software implements that chain verification correctly middle person attacks are definitely a possibility for TLS and SSL they do require interposition or the ability to the ability to still get in the middle of the traffic when you're a sibling so that works for CAN and that also works for like Ethernet LAN segments you can try to abuse endpoints that are implemented correctly you can try to change trust doors as practical as crypto breaks and then less rare but very practical is actually forced downgrades of the protocols probably not relevant for newer versions of TLS but was a problem with older versions and then some tools we talked about MITM proxy Burp SAP MITMF those are good ones do we have any questions on TLS and SSL I've been talking for quite a while no questions let's just take a a water break before you have to listen to me talk some more about heavy vehicles I'll give you a heavy vehicle crash course then we'll talk about seed key exchange and so that hacks on that be back in five minutes so at four twenty okay I'm back we're ready to go any second now remember perfectly fine to ask questions at any time we'll be going very quickly through vehicle networks and some of the protocols will be some discussion of attack trees and then we'll bring it all together with a discussion on how to break UDS seed key exchange so discussing vehicle networks talking about CAN this is a very common bus and automotive it's two wires it's actually sometimes faster than 500K the slides is between 250 and 500 definitely in heavy vehicles you'll only find 500KVPS so you can think of it like levels zero to two in ISO it includes kind of framing for some gory details on like how can actually works and when it doesn't I highly recommend the when can can't talk by Tim Brom and Mitchell Johnson and Grimm they do some really interesting research into how you could violate assumptions and the specification to get some error conditions and how to also deny messages in that CRC field there so applications on top of CAN are commonly going to pack signals into bit field locations for a given arbitration ID right so I've given you here a time series graph some measurement we could think of it as maybe velocity and remember CAN buses were introduced to replace point-to-point wiring of sensors so they are there mostly to give you time series information a sensor or an ECU will pack some of those sensor readings into a specific bit field location for a known arbitration ID other ECUs will wait for CAN messages of a known arbitration ID to come in and they'll unpack the signal from the known bit field location and they can have a window or they can look at the most recent value that's encoded in that window so the idea of this picture is that a time varying signal is being encoded in known bit field locations of a sequence of CAN frames of a given arbitration ID in this case 7263 alright so what about heavy vehicles in heavy vehicle networks the things get pretty complicated but the good news is that there's interoperability that has to happen heavy vehicles are put together by original equipment manufacturers and the people that make orders to OEMs get to decide which equipment gets inserted so brake controllers and transmissions and engines all have to be compatible on a published spec the messaging is J1939 the trucks have evolved over time and they now contain multiple segments so this is a picture from the textbook showing an example of several different segments on a heavy vehicle including one that has the ABS and engine in blue as well as something like telematics in red and some of the power train stuff in maroon and then various gateways and things that bridge and forward signals so it can be pretty complicated J1939 on heavy vehicles today you can find at least three J1939 buses on the diagnostics connector in the truck so there's a lot of buses and a lot of connectivity the way that messages are packed is kind of like what we discussed with the time varying signals but because of the interoperability that's necessary there's a lot more structure to the messages that are encoded and J1939 after you're done describing what data is going to be in the message can only really send 8 bytes at a time but there is a transport protocol in J1939 itself that can let you send more than that so we have a 29-bit arbitration ID in heavy vehicles which is extended relative to passenger cars there's still a control field data is update bytes CRC just like before so when we're talking about heavy vehicles the time varying signals that we discussed that get packed into bit fields those bit field locations are actually identified by SPNs and they're packed into frame types PGNs instead of arbitration IDAs and that's how they encode the time varying signals there's an example of a tool here that you can download and use to decode 1939 traffic because of the standard you can easily download the spec it's actually provided in the excel spreadsheet and you can convert that into a tool that can do the decoding for you so what else is J1939 for other than encoding time varying signals well the kinds of features that people needed from their trucks has only grown and J1939 is expanded to accommodate so nowadays J1939 can be used for reading firmware for doing ECU parameter reconfiguration for doing ECU diagnostics aka the fun stuff but of course it also does all the truck stuff like body control functions and immobilizers and ADAS trailers etc so now we're going to talk about a protocol called UDS specifically UDS Seed Key Exchange UDS is a unified diagnostic service it's known as ISO 14229 and when it's on CAN it's ISO 15765 it's actually used in almost all vehicle diagnostics protocols when we do this at Cybertruck you get to learn about it in quite some detail in other sessions I'm going to do my best to give you a primer on it UDS like I mentioned can do all the fun stuff reflashing and reading memory to test and to know when you're trying to do some of the fun stuff in UDS you have to first gain authorization to do so and when you try to do something that you're not authorized to do UDS will sometimes give you a negative response code it's called the security access denied the sad message so to gain authorization you have to actually unlock your current session using the security access cdp exchange in their spec what we're calling the cdp protocol the session holder actually sends out a seed and the session user has to return a key this is a 27 replies on 67 some details about the protocol there we're talking about in more detail so let's put that into the framework of the challenge response protocol that we've discussed it's important to note that it's only 16 bit space so it doesn't fit our ideal characteristics of resisting known plain text forgery attacks the seed is actually the challenge and the key is the response tried to color code them and highlight where 27 is used or 67 is used but it's very much the challenge response protocol that we've talked about before you have some crypto going on on the left and some crypto going on on the right and then some validation going on in the ECM so here's an actual traffic capture from one of Dr. Daly's papers if you look at the excel spreadsheet traffic capture you can identify when subservice 5 and subservice 6 are being used I've put the color coded arrows on it to remind you of which direction the traffic is flowing relative to the challenge response protocol diagram at the top so in this case we requested we being the diagnostic software requested a seed from the ECU and then we calculated a key and we sent it back and the ECU said yes or no so with all that information dump that I've given you it should be possible now for you to look at these traffic captures of J1939 traffic a select just selected messages from it looking specifically at the subfunction 5 and subfunction 6 on the diagnostics PGN and actually derive what the three seed key algorithms are so let me just return to the previous slide for a second you should be able to look at the traffic and actually describe in a closed form what the F crypto function is in either side because they match just from the traffic if you have questions feel free to unmute or to put them in chat so first little hint I'll color code the messages there I know when you look at can dumps for the first time it could be pretty daunting the thing on the left of the hashtag is the PGN and we mentioned that 18 DA is for diagnostics and then there's a source in the destination in the next 2 bytes because these are just specific target messages not broadcast so 2F1 from F1 which means that what you're looking at is you know the send and receive of the challenge respectively and so in the top left the challenge was 5B31 and the response was 5C31 so let's talk about the first 2 C key routines here in column 1 and column 2 the first one I'm showing actually both are pretty trivial C key routines the first one is simply adding hex 100 the challenge is 5B31 the response is 5C31 the challenge is 3632 the response is 3732 so we're just adding hex 100 to the challenge in column 2 the challenge response routine is even dumber you simply need to respond to 34 35 to no matter what is sent seems silly but the Tesla C key exchange was actually of this form and the key was 01020304 sorry the challenge was on 010304 and the response was 313234 so this is a little tongue in cheek to the Tesla C key exchange the third one is not as dumb as either 1 or 2 but it's still pretty dumb and I'll give you a couple minutes to look closer at the challenge response here to see if you can into it what the routine is what's the function I'll walk you through the solution there so if you look the challenge is 2C31 the response is 0005 next one 3132 has a response of 1DO6 and you can tell that it gets zeroed out here that's a clue that this is actually XOR with a key that has 2C as the byte for that position and if you were to do XORing of any of these pairs you'd get the whole key and it's just XORing with the key so pretty simple but not too uncommon for some of the things you might find in heavy vehicles and we'll talk about some more examples in the following so we're going to do an aside on attack trees and then I will show you an attack tree how to break some UDS seed key exchange and we'll wrap up before I go on to attack trees as an aside were there any questions on UDS seed key exchange were the hands on we did so first up let's talk about some notation for attack trees we'll use the example of an attacker to break into your house and steal something maybe in this example a passport not exactly relevant these days but hopefully we'll be soon we'll color code the nodes to try to communicate some estimate of difficulty and that can help us in modeling where you might want to put mitigations if this were kind of an exercise to design defenses or mitigations or give you an idea of what's the easiest way to attack if you were using it for modeling attacks so at the very top of the tree here we'll draw it at the left we're talking about objectives ideally when you're doing this modeling you want to have the objectives have a clear and unique impact to your stakeholder because that'll let you have clear risks associated with your modeling somewhere in the middle we'll have intermediate nodes and when you're putting together models of things that are non-trivial you're going to need to use both conjunction and disjunction so you're going to need to use and for some of the trees and then where you don't see and in this notation we're just taking that to mean or we'll see that we also number the nodes so this get into house has a 4.0 so it can be referenced later down at the bottom right you can create actions or events things you're not going to further break down in the model and this is where is a good place to assign difficulties so that they can propagate upwards you might also find in your modeling that you're going to want to mark certain events as out of scope not to say that they're impossible but to say that there's nothing that you might be able to do in terms of mitigation so there's modeling it any further and that can save you effort and try to curtail attack trees from ballooning out of control it's also very useful to create references to other parts of the tree so you might reference things that aren't shown in the trees they're outside references you might also be able to reference nodes that already exist so these can be references to more trees or references to concrete nodes and doing this will let you reuse your efforts to try to once again curtail the ballooning of attack tree and kashazis and then of course mitigations I think attaching mitigations to the trees is really what doing attack trees is all about and when you have mitigations attached to the attack trees you have the context of how the mitigation can impact the risk which is very useful so tools for doing attack trees is a lot of options some cost money some are free actually word smart art is pretty good at doing attack trees it will auto balance them for you and everything so if you already have word and you're doing a small scale tree it's pretty easy to use that physio is a good tool for this omni-graphil as well and there's also purpose built commercial tools that cost a lot of money I'm not going to mention any of them there's a bunch of free options you can use dot so graph viz dot for modeling graphs and plotting them there was a really great post by Kelly Shortridge recently about how to apply styling to these and to use them in modeling in threat modeling plus attack trees it's really great I recommend it you can also just use an invented text file in markdown and there's tools out there that will convert your markdown into trees you can also use my mapping software which is my personal favorite the mind mapping software is already kind of designed to let you look at very large interconnected trees this one tool mindmup saves JSON files they're easy to process so we created a tool that can post process the JSON and turn it into a full blown report including qualitative analysis so if you need a very large scale a thorough attack tree I do recommend looking at mindmup as an act trees tool okay so we're going to go back to seed key exchange now if you're dealing with a heavy vehicle and you want to get into an ECU you're probably either trying to get a security session so that you can do some of the fun stuff or maybe you're an attacker that's financially motivated and you would like to figure out how to pirate a security session so you can sell that to other people because they want to do the fun stuff well in the case of the goal of getting a security session on a small scale if you have diagnostic software in hand you can put a device on the bus and affect a middle person attack and just send the information you need from the diagnostic software to the ECU and boom you have a session if you don't have diagnostic software then even a small scale getting a session is the same as pirating it and we're going to expand on that particular goal using an attack tree as we see here is a model in the form of an attack tree for how to pirate a security session using the notation that we've covered so at the top level there's a five different kind of means to get this session the first you have to do two things you have to get the diagnostic software and one of extract a lookup table or reverse an algorithm and then for the second major option you have to get the ECU firmware and then reverse engineer it third major option needs captures and either solving for the formula or retrying until they're repeated and I'm going to go into detail in each one of these concrete notes so you'll note that we're modeling getting the diagnostic software obtaining ECU firmware and captures are all out of scope and they're impossible but that they're outside of the model there's no mitigations we could do with them they're just assumed to have happened and then of course in the two other major options are brute force and glitching which will be interesting so let's talk about 4.0 remember a seed key exchange with UDS only uses 16 bits which if you were to capture in a complete lookup table is only 128 kibby bits so is totally tractable John Mag actually did an extraction of the whole lookup table of a particular ECU and you can see he did it with 4 identical laptops to try to reduce the search time but it was completely effective and did extract the lookup table and then of course you can just reverse engineer the algorithm starting with the diagnostic software or something else look at the code that implements it and turn it into a closed form here you see a picture of using a decompiler in one of the Dr. Daly's papers you can also just brute force it so you don't have the diagnostic software you can't lift the algorithm you can actually just try every possible value for every seed you receive the worst case is 16 bit by 16 bit which is kind of too long but most generators cover all 16 bits so you'll see a picture on the left here of an actual capture from ECU if this were completely random it would be solid but what you're seeing instead is a straight line that's been wrapped around by a modulo operation so you could actually recover this particular seed key with y equals mx plus b as an example that the seed generators aren't necessarily going to cover all 16 bits and also reduce the search space by considering maybe you control the seed often times a hard reset will actually bring that seed back to the same number which brings you down to the single seed which is 110 minutes and 10 requests per second which is totally tractable basically the ECUs are supposed to have crypto but they're limited by 16 bits and so there's really not crypto it's just whatever you want to call it and that's what we're going to do with the seed exchange another fun option and this is from passenger cars but it was a really neat exposition where these researchers had already reversed one ECU in a family and they came across another ECU in that family and just assumed it was probably the same algorithm with different parameters so they set up a Z3 I think it was the minimum they were able to solve for the constants but 10 was guaranteed there's also the option to glitch past which is glitching is always amazing when it works when you're trying to glitch past the diagnostics authorization session check in UDSCP exchange there's actually a big time gap between when you have an observable trigger for what you want to glitch based on where the test is actually going to be performed so I'm trying to capture that here in this timeline you at one point the send key is going to happen on the CAN bus you're going to observe that but then there's multiple operations after that like the CAN controller actually receives the send key the ECU then receives that message from the controller and then the ECU compares it and those are all different clock domains so that's a lot of wibbly wobbly tiny whiny stuff in the way it can be very difficult to set up a glitch for that since producing this slide there's other pieces of hardware that have come out so riskier created a tool that can actually trigger based on the CAN the observation of the CAN messages and so if you had this device in hand you could look at the bus between the controller or maybe on the exterior of the controller I know Colin O'Flynn produced also a PHY whisper which is used for USB triggering it solves a similar problem and I'm told it could be updated to trigger based on CAN as well so in summary we talked about send key exchange I told you what J9039PGNs are involved what subservices are involved we talked about how to do all these various captures sorry all these various attacks and what to do when you have a capture or software or none and we put it into the framework of an attack tree so that you could think about it in a decision making process if you ever find yourself in the possession of an ECU that you need to crack are there any questions on send key exchange okay moving on and we're going to get into the closing section so thanks to everybody who stuck around to this point I hope you learned a couple new things I always enjoy talking about this material so I appreciate your attention and listening to me talk and talk and talk for 3 hours in summary we talked about the difference between classic crypto and modern crypto remember classic crypto is all about letters modern crypto is all about numbers when people tell you crypto is hard generally that means that correct crypto is hard to break if you only have the capture but sometimes you'd have other things right if the crypto is wrong sometimes you have control over the software executing the crypto so assumptions can be broken remember that the crypto building blocks don't usually get broken especially if you're talking about block ciphers or correct crypto but how the crypto is put together into protocols is often where those crypto systems fall apart if you're trying to test a protocol you might get the places where it says shall and see what happens when it don't sometimes crypto protocols get broken by side channels sometimes crypto systems get broken by compromising the execution environment so software exploitation or info leaks remember that for TLS and SSL middle person attacks are very effective and definitely worth testing and remember that for seed key exchange there's a lot of options including lifting, reversing, solving and brute forcing to get your way through that crypto that's all I have for today here are a whole bunch of resources for your continued learning if you want to go forward highly recommend crypto pals great set of challenges I love the work of Angel Bertini in particular this let's play with crypto presentation for when you really want to get it deep into stuff pretty much every stack overflow answer by Thomas Pornay is 100 you should read security engineering by Ross Anderson the second edition is free just get that PDF and read it and then for more entertainment you have the potato set crypto puzzles and of course POCR GTFO once again thanks everybody for your attention I'll see you around the conference I'll stick around here and chat for questions should you have any for another 10 minutes or so cheers everyone remaining I'm closing the room in 5 minutes thank you a lot Ben that was great hey David thank you for all your moderation yeah it was pretty easy cheers we'll see you around the conference yes bye