Threat vectors. A threat vector, it's also known aka as an attack surface, is an avenue that an attacker can use to exploit or gain access to a system or cause a system to leak information. Much like we saw with the image being encrypted with just electronic codebook. Still it leaked. We thought we were doing a good job. We're doing using AES-256. That's a great encryption algorithm but the electronic codeword codebook version of it has some weaknesses and can leak information. So, during the process of engineering systems, you have to always be asking this question: "What is it that we are trying to protect against?" It's very hard to protect against all threat vectors, because there are some really crazy things that we'll see here in minute, that people can do to your system if they have time and they have money and they're very determined. They're probably going to get in. Be constantly applying the security mindset. How can I break this? Where is the weakness in the system backup? The woodblock puzzle. Going back, what if you assembled it outside the outside box versus trying to assemble it inside the box? Coming at from the problem from other angles, always be thinking about and revisit your assumption. Question your assumptions. I like this one. So, a brute force attack on AES-256. So, AES 256 has 256-bit keys. That's the key length for AES-256. So, that's two to the 256 which is 1.15 times 10 to the 77th possible keys. It's big number. So, using one trillion computers. Trying one key per picoseconds. So, we're doing 10 to the 24th key attempts per second. It would take, do the math, 3.7 times 10 to the 45th years, do a brute force attack. So, nobody does that, because it's computationally prohibitive. It's computationally expensive. Quantum computing, when that becomes practical, the concern is, is that we're going to have to greatly increase the length of our keys. Because the promise of practical quantum computing is that it could be possible to brute force attack in a reasonable amount of time on a key length of 256 bits. I'm not personally aware of a working quantum computer system that capable of doing something like this. Does anyone known differently? You raise your hands, speak up if you do. I'm not aware of it. Okay. So, tagging AES, so here's these big, steel strong, safe AES. Can't get in, can't guess my keys because it just takes way too long. So, an adversary comes in and he just bounces off AES-256 and he beats himself up, maybe runs at that for awhile and he finally realize, "This is pointless. I'm never going to guess the key." So, got a decent amount. So, he stands up. He dust himself off and he says, "I had the key though. I could steal the key. I could open the gate and get in." Yeah. So, protecting keys and key management becomes the tricky part. That's where things start to get interesting. So, you're using known algorithms, you're using AES-256. It's all about protecting the keys and key management. Making sure that the adversaries cannot gain access to the keys. That's the end. It's the hard part. I'm not going to go into a tremendous amount of detail about techniques for protecting the keys. It's beyond the scope of this course. Eric Wustrow and his security course may go into greater detail about that, but it is where you can get clever. This is, you don't want to modify the known algorithms, but you can get clever. Imply your engineering knowledge and skills in ways to make it hard for an adversary to obtain the keys. Yet, we never modify known algorithms. So, and one of the reasons why you don't want to modify known algorithms is generally, if you have a cryptographic system you want to get certifications from various authorities, like FIPS and NIST and so forth and customers request this and sometimes require it for certain products. You have to have such and such a security certification and that means taking your product into a lab, a certified lab like UL labs or these other certified labs and they test your product. One of the things they'll do is, they'll give the drive or the drive, yeah, I'm working in storage too long. Give your product a set of data and a key and they know what the response is supposed to be. So, I think that give your system some data and a key and they know what the answer is and say you're doing AES-256 with XDS mode. They will give the data and the keys for that and your device has to produce the response and then they compare it against the known answer and okay, if all the bits match, then you get the stamp of approval and you can put that label on the box on your product and you can put it on your website and you can use it as advertising, "Hey, we're such and such certified". That's why you always want to use a known algorithms. It's one of several reasons. So, each keys you have a single-purpose. Ideally, in an ideal world, one key and one purpose. How many people reuse passwords? I do. I'm getting away from that now though. I let my Mac choose passwords for me and when I found some, I found a password that was 1234 a couple weeks ago and I need to go change that. Incredibly easy for an adversary to guess that key. Guess that password. Vulnerability of the keys increases is a general idea, a general notion, a general trend. The more you use it, it's vulnerability goes up. The more places you store it, can get stolen and the longer you have it, someone might guess it. Just some things to be aware of. So, here's a notion. So, Alice's got all these private keys, these secret keys. She's chosen to use some kind of a product or a database to store all our keys in and Alice provides a very strong password. Something some character string of gobbledygook numbers and letters and symbols and whatnot and that password is used to encrypt these keys and they get stored in this encrypted KeyStore database. If this database is stolen and the adversary does not have the password, then those keys are useless. It's just gobbledygook and then when Alice wants those keys, he provides the passwords and the key can be taken out and decrypted provided to you or to fill in a web form password or whatever. But this, what's going on here is calling wrapping the keys. So, Alice is taking her private keys that she wants to keep secret and private and wrapping those keys with the strong password as an encryption key. So, that's what it means when you hear the term wrapping. All these keys that are in this database are wrapped with the password. They're wrapped with another key. One key is encrypted with another key. There can be chains of these. This key can be encrypted with this key which is encrypted with another key. So, that's what that term means if you hear that. What is wrapped? Very difficult problem to get around, this was called, "The man in the middle attack". This case, Eve is the man in the middle and again Alice wants to receive secure communication from Bob, but Eve has inserted herself into the picture here. So, Bob sends his public key. He's got a public and a private key here. He sends it across an unsecured network where Eve is hanging out waiting for it. Eve sees it and goes, "Aha! There is Bob's public key." Can you handle that and sneaky Eve here has generated the wrong public and private key pair. Unbeknown to Alice over here. So, Bob takes his message again. Hi, Alice. Encrypts it with his private key. Gets a bunch of gobbledygook data, sends it. Eve sitting in the middle, here and feeds it into decryption algorithm with the public key producing the original message and then sneaky Eve uses her private key to re-encrypt that message from Bob using her private key. Okay and creating a different scrambled gobbledygook mess of characters in a binary pattern and forwards. When Bob sent the key, she saved Bob's keys and she forwarded to Alice her own private key because Eve didn't know of that. Eve was hanging out here in the middle. So in any event, Eve receives this, decrypts it, and Eve, excuse me, Alice believes that she is communicating securely with Bob. This is a tricky one. Everyone see what's going on? Okay. So, really what once someone has established themselves in the middle like that, it's really hard to get around that. It really requires establishing some type of secure communication channel that Eve can't eavesdrop on one, so that Bob can ensure that his public key actually gets over to Alice to use. One way that you could do that is, once Bob has sent his key "Hey, Alice I'm going to send you some encrypted messages." They could fire up a Skype session, and Alice could print out Bob's and display Bob's key, and Bob could look at it "Go yeah, that's my key." It was on the previous one, here this might be, I'm just going to make up an example A5, A5, A5, A5, A5 is Bob's public key, but it's over here. When Alice displays on a Skype session, the key that Bob sent, and it's 1-2-3-4--2-3-4-1-2-3-4-1-2-3-4, Bob's going to say, "Hey Alice, that's not my private key, someone inserted a key, that's some kind of key swap." That's an example. So, you could determine some kind of shared secret but through a phone call, or meeting in person, could use Diffie-Hellman. But I think even with Diffie-Hellman, I think Eve could insert herself in there. Not a 100% on that, but because they have to agree ahead of time on a shared number, through a phone call or something, through some other means that's what this pipe is supposed to represent something that Eve can't listen to. Some way you need to get this information from Bob, exchange this information between Bob and Alice. Replay attacks. So here, now we're not talking about people communicating, but we're talking about machines communicating with each other. So, there's a node some place in the system, or server. Something that wants to send a message to a lock, to unlock the lock. So, well what do we use when we want to make sure the message is authentic? We use a message authentication code, a Mac. So, the sender has Open Lock command, got the private key, runs it through the Mac, creates a tag, sends a command and declare. The receiving side has the tag, takes the private key, the shared secret, Open Lock, max it, compares, and the lock opens. That's all great. Pesky Eve was listening, and grab the tag, and grab the command, and now, at a later time, when no one's watching, Eve wants to get into the building, because they've got Reese's pieces in there, and she's after those. Eve sends the Open Lock command along with the tag that she snabbed, and tags match, and lock opens in, and she goes to get her Reese's pieces. So that's a problem. How do you stop a replay attack? So, take a minute and talk about what a Nonce is. Has anyone heard of a Nonce before? Raise your hand if you've heard of a Nonce? Is there any? Good. A couple of you. Yes. Nonce is a combination of a number used once. Choose one time in a cryptographic system, and never ever to be used ever again. In its simplest form, it can be a counter value. Counter values might be guessed. It was one of the first things, if an attacker understands that a Nonce is at play is going to start with zero, and go, or he or she will go 0-1-2-3-4-5-6-7-8, and try to figure out what the sequence of the Nonce is, can be guessed. A better approach would be to use a pseudo-random number sequence. Now, I said earlier, cautioned you against using a pseudo-random number as a key. Pseudo-random LFSR might be a reasonable choice for a Nonce, because it's much more unpredictable than a counter, but it still might be guessed. An even better approach would be to use an unpredictable sequence, and I'm not going to get into what unpredictable sequence is, but I'll just leave you to think about that. That's the ideal. The ideal Nonce is something that is unpredictable. But, it can be one of these three, and even if it's a counter, can still be effective at defeating a replay attack. So, here we go back to our replay attack. So now we take the Open Lock command along with the private key, the shared secret key, and this Nonce value. We feed that into the Mac, and we generate a tag, some unique value, and we send the Open Lock across the insecure communication channel. This process happens again, so the Open Lock command along with the key, and the Nonce, both sides have the Nonce. They have to establish the same Nonce value on both sides. Assume that that's happened, we get a tag, and compare the transmitted tag, the same lock opens. Eve's here. Pesky Eve's hanging out in the middle. Darn her, she snab those values, the tag and the message. But the moment the message was sent, and the lock opened, both sides incremented their Nonce to the next value, whether it's a counter, whether it's a LFSR value, or whether it's some kind of pseudo-random number. Point is the Nonce is not the same value anymore, and that's key. Now, Eve sends the tag she grabbed along with the message, and because the Nonces have advanced, this tag is not going to match the old tag. Because the Nonce value has advanced, and no, the lock doesn't open, and so she doesn't get her Reese's pieces. She goes away home. "Oh I wanted to get in there, and steal Reese's pieces." This is a way to defeat the replay attacks. So drive home the point here, every communication channel, in and out of a cryptographic module needs to have security concerns addressed. So, here's a cryptographic module, it's a secure server, the sending node, it's sending commands, it can send code updates, it can request status of this other end node that's also a cryptographic, or secure module. So we want to use Mac functions, and probably combined with Nonces. I didn't draw the Nonce in here, but with Nonces, to verify that the commands that are being received are legitimate. In this case their sharing of secret key. Up here's just a batting again with a little board I found, I don't even know what it does, I just go to Google Images and see single-board computer print circuit part trying to get all these pictures, oh that one works, a square about the same size as the square I drew before. So, just imagine this is an Ethernet connection, and so when this end node is receiving these commands, it's checking the received tag against the computed tag using the secret key. I've seen this technique used also. This is a challenge and response idea. I don't if you've encountered this before in your studies, or work, or in your life. When a message comes in, this end node has a list of Challenge Questions and Challenge Responses. So a command comes in, I want to communicate and maybe there's some ID that's associated with the command. So this command comes in, and I want to communicate, and the system sends a Challenge Question back to the receiver. Excuse me, the sender, sends it to the initiator of the person, or device it says, I want to communicate. That system then has to respond with a known answer, in that responses looked up in the Challenge Response table. So it was a Challenge Question Five was sent, and if the received response match the contents of this, the response five, and the challenge table, and those are equal, then a communication session could be established, for example. That's a way to do it. I would add Max and a symmetric encryption on top of this. You could do it, it could be as simple as this. It all depends that goes back to that question, what are you trying to protect? Do we really care if someone gets in here? How much harm could be done if someone gets in there starts messing around with the system? Does it really matter? If it's a toaster, what are you going to do? Are you going to burn the toast? Or a ridiculous example, my toaster got hacked this weekend, I can't make toast anymore. Is it bank? Your medical records? Something like that? Oh, that's a bigger deal, right? You don't want people in there, taking, transferring money out of your checking account. So, how important is the information we're trying to protect? What threat vectors do we want to protect against? How much work do we want to put in to protecting that? These are the questions as engineers whether you're designing and building systems you have to be asking.
