Encryption: A Deeper Look By Adam Perella

‍

Encryption: A Deeper Look With Adam Perella

One of the best ways to build quick knowledge about a topic is by listening to an expert talk at a conference. Adam Perella, PCI compliance expert, from Sikich is the person you want to learn about encryption from.

Attendees at PAYMENTSfn were treated to a great talk by Adam, which explores the mathematical foundation of encryption, and progresses to explain the different methods in use today.

Encryption is a complicated topic and a difficult one to present to a large audience. It's especially difficult to be entertaining and deliver this information with perfect comedic timing, but Adam does just that.

Watch above and read below for a rough transcript.

Transcript of Encryption: A Deeper Look

Adam Perella:       Good morning everyone. Look how excited this guy is to learn about encryption. He's pretty stoked. I hope all of you by the end of this are just as excited to consider encryption as something more than a deployment. So a little bit about us. Sikich is largely an accounting firm. We also do advisory services. Our little division does security and compliance. I'm not going to bore you by reading out loud what is already written. If you have any questions on security or compliance, please come to see me afterwards.

Adam Perella:       Our division does everything from penetration testing, a lot of PCI, PA DSS, P2PE. I lead the digital forensics team, which is on this slide, but I have been working at payments or largely with payments for seven years, assessing a lot of companies, merchants, payment gateways, service providers, issuers. So a lot of experience. And on our team, we focus a lot on collaboration, understanding the issues, not only what our staff are facing, but their customers because we want to provide the best service possible.

Adam Perella:       So on the agenda today, outside of having an incredible amount of fun, we're going to go over all of this. Please pardon the fact that I'm going to be flying through a lot of this. Encryption is a very difficult topic. The math behind these operations is complex. We're going to go through a little bit of that. Everybody who woke up this morning said, "Hey, I really want to know how RSA works," today's your day. You're going to figure it out. And if you didn't say that, you're going to think afterwards, "Hey, I'm really happy I attended this fantastic presentation."

Adam Perella:       So an overview of the basics. You've got some metrics. So when you think about a symmetric key, this is the key that you use to on lock your door of your house, right? You have the same one that locks, the same one that unlocks. Symmetric keys are very common. When you have a pre-shared key between ... You have a password you're exchanging with somebody, that operates under the premise of symmetric encryption. Asymmetric, however, is two keys. So now you're going to have one key that performs encryption operations and one that does decryption. The one that does encryption is called your public key. So if you're encrypting data and you can't decrypt it, you can share this key with everybody. This is the beauty of the public private key pair system. And every time you use a website and you see that HTTPS, that's secure. The end of that is built on asymmetric encryption. So we don't have time to take questions throughout any of this, although I'm sure you guys are just riveted. Please ask me afterwards and we can talk about it.

Adam Perella:       So we're going to talk about ... Well, we're not going to be able to go into too much depth, but symmetric encryption is fast, right? You got one key, encrypt, decrypt, very fluid, while asymmetric is a slower operation and the keys are much larger. So as we'll discuss in a little bit about key length and key strengths, the NIST 800-57 part one revision 4, everyone knew this one, right? Yeah. If we were in a professor seminar, I'd be like, "Look it up." So if you don't know NIST, find out about them. They've got a lot of really riveting manuals. They read like a mystery novel except you solve the universe.

Adam Perella:       So prime numbers. If you don't remember, a prime number is divided by itself and one, nothing else. And you've got this cool graphic we threw up here, which is going to go through those. But prime numbers, there's a lot of them, and you might be able to conjure up 20, 30 in your head before you get confused. But they get really big really quick. And the beauty of a prime number is that it makes calculating sub-values therein impossible, right, because it's just one and itself. So for cryptographic operations, prime numbers are key.

Adam Perella:       So keys and key management. You don't need to know how encryption works at a really granular level. You do need to always remember that keeping your keys safe, the keys that decrypt data, is the root of what I'm trying to get at throughout all of this. So key management is really, really important. If you don't remember anything else I'm talking about, remember that statement.

Adam Perella:       So to begin, some of the nuts and bolts, a block cipher. When you want to encrypt the data with either a symmetric or asymmetric key, you can use a block cipher to do this. So you're going to chunk that data. You're going to chunk that data up and you're going to encrypt each separately. So has anybody ever here heard of block cipher chaining, anything like that? We've got a few hands. Fantastic. So at its base, right, when you start chaining these encryption operations together, you're requiring one to feed into the other, but that requires an initialization vector. So the initialization vector, the initialization vector is just random data you throw at the beginning. Think of it like an assault for hashing. It's something that you are putting into the beginning of an encryption operation to make the subsequent data unpredictable. When you think about encryption, everything you want is unpredictable.

Adam Perella:       So with the types of block ciphers, you've got all of these. There are many more. Electronic code book is kind of the beginning of this, and cipher block chaining is by far the most common that we see. But you have cipher feedback. Ultimately, after electronic code book, all of them are very similar except they have some different way of when you're feeding it the previous self. So let's walk through some electronic code book. Pretty cool, right? I see a lot of smiles. Fantastic. Don't ever use this, just as a side note. You're learning about it, you're like, "Oh yeah, that's pretty cool." Don't ever use it.

Adam Perella:       All right, so the reason why you don't want to use it, so you're breaking these up, you're going to encrypt it, you're going to store it, and we've got a cool graphic here. This is from Wikipedia, by the way, this nice little write up online about this. So you've got your plain text, you've got your key. You're going to take that block, you're going to encrypt it, and then all of this data is going to be exhorted together at the end, and that's your encrypted value. That's the data that no one's reading. So the benefit of this is that if you break one block per chance, the rest of it is still going to be decrypted, and then decrypting is the the same process.

Adam Perella:       But with that consistency, I know that this is a graphic, but values can be predictable. This is less of an issue in what you are encrypting is say a book, right? A book is not going to have a lot of repeating values in it. But when you have card data, I mean, think of how many values have the same pan. So you've got the same first ... You've got a three, four, five or six at the beginning, right? You know what these values are going to be. So if you're just encrypting that 16 digit pan, you're going to start to see patterns really quickly.

Adam Perella:       We were working with a service provider who swore that this couldn't be broken. They're like, "Oh no, no. We're good to go. There's no way you're going to get it." And I was like, "Fine. Export your database. Let's give it to our pan testers and see how long it takes." So 21 hours later, we had the key. We handed it to them and that was an ad hoc test. So when you think about the exposure, obviously, you never want anybody to ... You wouldn't hand your database over to anybody. But it is a concern you should have because if you are practicing key management and if someone was in your environment, then they could still get at that encrypted data.

Adam Perella:       Let's talk about cipher block chaining. So the operation flow is that you're pulling in that entropy further on. Man, this is going fast. I'm really happy you got that clock. So we're going to keep this moving along. So you've got a series of steps. Again, when you chunk this data into blocks, each block needs to be filled and the block's not filled, you add some padding. Padding is just typically zeros or excess value to put in there to complete those blocks. So initialization vectors are really important here. Initialization vectors per NIST guidelines should be unique per record. If you have the same initialization vector, the same random value that you put at the beginning and it's repeatable, then again, you're going to have those same repeated efforts later on, which is what you want to avoid.

Adam Perella:       So when a database, you can store the initialization vector in plain text right next to your cipher text because the amount of time it would take for them to programmatically take that initialization vector, decrypt that data, is excessive for getting one value, so just a thought there. And then a break of the chain will cause a failure. So as everybody knows, the integrity of their data is really important and it wouldn't matter. You wouldn't want any part of your data to be missing. So in this model, again, wonderful diagram. I wish I'd have built this. This is nice. You see how the initialization vector is fed in, [inaudible 00:11:10] and then it feeds back in. So you've got this chain of operations to make this work. This is exciting, right? Everyone's feeling really good. Yeah, I mean, this guy has got crazy smile on his face. I like it.

Adam Perella:       All right, so entropy, right? So what is it? So you probably heard this in college and you were like, "Oh hey, that sounds really, really cool, tending towards chaos," and you got the [inaudible 00:11:37] eating its tail and you feel all deep, but it's more than that. It's also needed to make encryption useful. You need good random. You need something on predictable. If you can predict keys, then you can predict the output.

Adam Perella:       As a side note, if anybody wanted to just blow $200 and have their mind shaken, get to TI-85 calculators, you know those old ones that you had in high school that you made the crappy graphics on? Get two of those and ask each of them to generate a random number between 1 and 10,000. They're going to come up with the same number, and then you do it again, the same number, the same number. Because computers will only do what we tell them to. So understanding what is random and what is not is essential, because if you don't think that organizations trying to understand how you're encrypting data aren't trying to tackle this problem, you're wrong and it's not some pimply kid in a basement. These are devoted people because there's money involved.

Adam Perella:       So sources. You've got /dev/random for Linux, and you also have get random. If you want to go down the semantics of urandom and seeding, we can do that later, but /dev/random is better than urandom. Your crypto AI, Microsoft does a pretty good job now of of generating random data, and then you can also do this manually. Common sources of random involve mouse movements, keyboard values, fans, et cetera. And again, ultimately your entropy is to remove the ability to predict the outcome and make strong keys. So rephrasing it, it sounds better one way or the other, [inaudible 00:13:31] makes you feel better, but ultimately that's the path. So who wants an RSA exercise? Please, please keep your hands down. This is where it gets riveting. So bear with me here, because you're going to have flashbacks from high school calculus and if anybody gets the shakes or starts crying, I understand.

Adam Perella:       So understand what a modulo is in math, modulo and modulus. So we've got some fantastic examples here. If you divide 5 by 2, your remainder is one. You divide 11 by 2, you can forget the 5 remainder 1. Forget the 5 for a minute. You're just looking at the remainder. So if you divide 31 by 16, you're only getting like 1 with the remainder of 15. Everyone with me so far? Good. It gets a little bit more complex.

Adam Perella:       So if we look at the word test, right, we're going to break this up. If anybody remembers Deedee's slide from yesterday, it's the exact same one. I was like, "Wow, we've got the exact same ASCII slide. I see we frequent the same sites." So these values, if you can see here ... Is there a laser pointer in this thing? Let's not blind myself. Okay, you can see the T decimal [inaudible 00:14:54] 84. The idea is that you're going to convert this into decimals, so it's something that you can work with.

Adam Perella:       But now we are going to get into the math behind it because math is exciting. So when your computer is generating a public private key pair is going to pull really large prime numbers. We're going to use basic ones for the purpose of this sample. So don't think a computer is going to be picking 11 or 13 for your public private key pair. Wow, that all came up really fast. Let's go back. I know I just destroyed the excitement. It's like reading the end of the book. Why are we going forward?

Adam Perella:       Okay, so it's like there's a delay on this thing or maybe I'm just hitting buttons. Okay, so from 11 and 13, you're going to multiply them and that's going to give you N. You're going to subtract one from each. You're going to multiply those and you're going to get Z. That's called your totient, right? That's not a made up word, but now all of your Words with Friends competitors are going to be furious when you spell totient out. You'll be like, "Wow, it's the seven letter word I've been waiting for."

Adam Perella:       All right, so when when you have that ... This is again, programmatically, but if you're willing to make your own key pair, you could do this. You need to select another value, and it cannot be evenly divided by Z. It needs to be between one in that. So we're going to choose seven. Everyone with me so far with all these variables? Well, I'm not going to get into the extended Euclidean algorithm. Wow, that's a fun one, right? We can have some coffee, share a tear, discuss math, but we're not going to do that today. So it's the greatest common divisor. And without getting into the math behind that, 103 is your value there. But if you wanted to multiply this out, you're solving for D because it has to equal one. So you with me? I know, I know. It's a lot to go through, but these are your variables. So if you go back to this slide and you're like, "Oh hey, now I know 11, 13, 143, 120, 7, 103," there you go. It's super easy, right? This is simple.

Adam Perella:       Okay, but you have to understand that ultimately what you're looking for is then E of N and D of N. So I shouldn't of N, and N. And the beauty behind these values is that you're trying to mathematically connect two numbers such that when you create them, they can work together, but you're not going to be able to calculate one and then the other. So it's like tying two values together that you're not going to be able to discern like, "Hey, I know once so I can get the other." And that's the beauty of the math here. So if you go back to the previous slide and you're like, "Oh hey, that's awful. I never want to experience that again," that's okay. Your computer will do it for you. But though that awful experience you don't want to understand, or maybe you don't feel like going through, is what ties those numbers together.

Adam Perella:       So now you see it in action. So if you take the word test, right, we've got the values up there, and you do 84 to the 7th, [inaudible 00:18:24] 143, you get 72. That mod is your remainder, or that the N value is your remainder. So you concatenate 72, 108, 8 and 72. That would be your cipher text. That would be unreadable to you. So you can hand that out and be like, "Hey, good luck," because who's going to guess that I needed to have those numbers go to the 103rd power and then divide that by 143 and keep the remainder in order to get the decrypted values 84, 69, 83, 84?

Adam Perella:       Really cool, huh? Does everyone get this? Yay. No? I know it's a lot, but we're trying to simplify a complex operation here. When you think to yourself, "Wow, now I understand something I'm never going to use again." It's not like this is going to be on Who Wants to be a Millionaire, like, "Explain a totient to me, Adam." It doesn't happen, but this is valuable because these keys, your asymmetric keys are used everywhere and you can use them in even more places.

Adam Perella:       Before I get to this last one, which is the meat of this discussion, we need to talk about key management because without fail, the biggest issue we see on the forensic side or on the compliance side is poor key management. When you have a private key on a public private key pair, you need to protect it. You can't share it. That's why it's called private. When you have an asymmetric key performing operations for your database, you can't have it just sit and stored in plain text on the database for everyone to read. I'm saying this to you, and you all might be like, "Yes Adam, this makes complete logical sense. I would never do such a thing." Go back to your organizations, please, and ask them where their keys are stored. They should know where they're stored and how they're protected and if it's not understood, they need to find out and they need to document it because those protections are what define the security over your most sensitive data.

Adam Perella:       I mean, I'm really just stealing my slide or I'm just going to undermine myself here. So your best practices are choosing an appropriate key strength. This needs to be in relation to the data you're working with. You're going to use access controls, so you're going to make sure that standard users or regular users can access it. If you're able to query a database as a standard user or general user and get to the table that has your key values, that's not going to be very useful.

Adam Perella:       Maintaining the integrity of the key, you won't want to be able to corrupt it, replace it. It is not uncommon in a payment application to have a key. You're like, "Oh hey, I've got my data encrypting key. It's encrypted with my key encrypting key. I'm good to go." Well, can I just replace your encrypted data encrypting key and toss in a null value for the CAC key, encrypted key? And then I'm going to encrypt all the data with my new key and I will harvest to that data later on. Unfortunately, that happens. So integrity of the value is important.

Adam Perella:       Does everyone here know what an HSM is? Wow, good. I got a few hands. Fantastic. If you want to do key management and you don't want to have to deal with the difficulty of access controls, an HSM is literally built to solve that problem for you. Really expensive. So I hope nobody's thinking about going in on a shoestring budget and buying an HSM because you're probably going to drop 50 grand on a box. It doesn't come with flowers. It doesn't make you coffee, but it does keep your keys safe.

Adam Perella:       And then performing a key rotation appropriately outside of PCI where someone told you that you had to do it, keys have a lifetime for a reason. Keys can be predicted over time. But you need to think about exposure of public keys should be limited to a certain number of transactions, and we're going to see that here in a minute. So for key strength, if you don't remember this document before, you're going to see it again. And as a side note, NIST came out and said that the triple des or your 3TDA is now considered deprecated, was the word they used. So if it's in current operations, you have until 2023, but you shouldn't use it for any new applications.

Adam Perella:       As a side note, I think this is important for people to visualize. You may have heard of an AES 256 bit key, right? Pretty solid length. The equivalent key strength of an RSA key is 15360. Now, for those of you who have not generated your key pair, you're probably going to think 2048 good. And that's not bad. And you may even think that you're going to go the 4096 route, which is [inaudible 00:23:34]. And that's an even better key, but rarely are you going to see anybody generate keys larger than that. It's because those operations are longer and an asymmetric key is going to be size-wise larger, which is why it takes longer programmatically to use those for many operations. From the same document, and I had trouble fitting it on the slides, so this is what you're stuck with. But you can see here that you've got your crypto period defined by this. This is a guideline. Ultimately, you really want to think about what you're encrypting, how you're storing it, what the use case is and the exposure of that data. Holy cannoli.

Adam Perella:       Okay, so keys may be exposed during rotation. Think about that. With something sitting on a box, if malware is sitting on a system that's going to perform key rotation operations, it can get that data from memory. Security through obscurity is not okay. I don't care how many times people want to write their own encryption. You can't break a key up and hide it in multiple places. You can't be like, "Hey, I'm going to route 13 this thing and no one's going to know what I'm doing." Doesn't work. And so security through obscurity is what we call that, and it is not a control.

Adam Perella:       Okay, applying this to payments. So payments-related usage, protecting cardholder data storage. Whenever that cardholder data is written in disk, even for a moment, that's considered cardholder data in storage. So I don't care if you throw it into a table and you're deleting and two seconds later. That's still written to disk. When you write something to disk, it can persist in memory. It can persistent in unallocated space. And if you would love to have me talk to you about why deleting data doesn't mean deletion from overriding, we could talk about that later. Come on by.

Adam Perella:       Digitally signing applications is another fantastic reason to use encryption. Your asymmetric key pan, we're going to go over this a second. And I'm sorry for speaking so fast. I just realize I'm under the gun here. I talk too much. So digitally signing things. Who here has at least heard of digital signage? Very good. Who here uses digital signatures? Not bad. Good. Okay. We're going to cover that in a minute, but very useful. Sending emails. If I want to send data to somebody else, I say, "Give me your public key." If you have a public private key pair, you will give that public key to everyone. Post it on a billboard. Take an ad out in the newspaper because people still buy those and post it on that. You can share that with everybody and it's nothing where they're going to be able to get at your information. They're just going to be able to encrypt data. You've got the private key, you're not sharing it.

Adam Perella:       And keys are unique to each customer. When you're using keys and you're accessing their environments, so by a VPN, if you were storing cardholder data that you're sharing where that customer has that key, keep it unique per customer because if their environment is encrypted, it's not going to compromise your other customers. If your environment is encrypted and that one key is exposed, you're not compromising your other customers. It's compartmentalization of that control, including keys for remote access. So I don't know how many of you have access to multiple customer environments, but it's something you really need to consider.

Adam Perella:       And this doesn't apply to all payments situations, but this is really important. Protect your keys. You wouldn't leave your keys sitting in your front lawn. You wouldn't be like, "Hey, who's going to come by and see my house?" Protect your keys, because it only needs to happen once and then your data's gone, and then you get a call from me on the forensic side, and no matter how bright and shiny I am in the morning, no matter how good the coffee I bring is going to be, it's still going to be an awful day in your life. I mean, no one wants to be breached.

Adam Perella:       Okay. So do you really need to store cardholder data? Most often when we ask companies this, they say they're storing it because they've always been storing it. If you don't need to store it, don't. Many companies, including Spreedly, offer tokenization services, so give them your card data, your PCI applications, meaning that card data lives in memory. Your scope has just increased. Segmentation controls can reduce that even further. Store the token. Spreedly uses one low value token so it's only going to be useful coming from you. This is fantastic. Your risk exposure is minimal.

Adam Perella:       Consider what is being stored and why. Maybe you store PII, maybe you have intellectual property, maybe you are sending contractual agreements between customers. Understanding what you're storing and how you're storing it dictates the keys and the controls that you have over that. And then data retention. How are you going to store that data? Are my databases being backed up as well [inaudible 00:28:34]? All right, thanks. Are my database is being backed up? Are my keys in those databases being backed up? These are things that you need to consider because security isn't hard but it doesn't have to be awful. That could be a marketing term.

Adam Perella:       All right, so digitally signing. So we talked about this before. That RSA, little math test we went through, goes both ways. So you can take your application. You can hash it. Everyone knows what a hash is. I didn't cover that at all in this presentation. So it's a way to take any value of data and you're going to get a set length output that's unique to the out, the in, right? So you've got Library of Congress, 64 characters. Four letter password, 64 characters. That hash is going to be signed. So you're going to take that hash. You are going to encrypt it with your private key so you never share that, but they've got your public key and then you're going to send that with your application.

Adam Perella:       Your application, when it's received, the digital signing process is to look at the hash of the application. It's going to take your public key, decrypt the encrypted value. So it's going to see the hash that you computed on your side. It's going to compare the two if they match, the program runs. It's fantastic. That way, you maintain the integrity of your data, the authenticity of the package that you have provided to your customers. Relatively easy to implement, offers a lot of security, strongly recommend this control. It's truly wonderful. So another good tip for you. And when malicious software tries to run, they want to put in a a subset of code, this would prevent that from being executed. Does not prevent this from happening after the code is installed, after it's in place, but if you have other controls like file integrity monitoring or similar, it'll prevent those from running.

Adam Perella:       We're almost there. So encrypting email. You've exchanged your public key with somebody, right? You guys want to send me sensitive information, I'm going to give you my public key. You're going to use that. And if you don't know how to use this, you can go to this link. If you go to my LinkedIn, it includes a link to this and it is literally a very long but with pictures, how to generate your public private key pair, how to encrypt messages and how to decrypt them. It's a really nice walkthrough and I love feedback. So thank you so much for listening to this. I hope that you all gain something from it. And thank you to Spreedly for having me at the conference.

‍

Download the Payments Orchestration eBook Below