Call Today 1-877-740-5028

Encryption at the Software Level: Linux and Windows

June 18, 2013 2:00 pm

(Save to cal)

Online

Encryption at the Software Level: Linux and Windows

An informative/technical webinar on encryption at the software level in which Mark Stanislav, Security Evangelist at Duo Security discusses encryption for Linux, and Farooq Ahmed, Software Development Manager of Online Tech discusses encryption for Windows.

Title: Encryption at the Software Level: Linux and Windows
Description: Farooq Ahmed, Software Development Manager for Online Tech and Mark Stanislav, Security Evangelist for Duo Security, provide an informative webinar on encryption at the software level for Linux and Windows.  Farooq and Mark discuss how encryption can be applied at various levels, from the software application code. Impacts on performance, backup, security, and available resources may suggest very different encryption implementations. This webinar explores the variety of places where encryption can be employed to mitigate risk of data loss or breach, and some of the considerations for choosing the most appropriate method to employ.

 

 

 

View Slides


April: Hi, everyone! Thanks for joining us again today. This is April Sage from Online Tech and I’m very pleased to welcome everyone back for our second encryption webinar in our encryption series, Encryption at the Software Level - Linux and Windows. I am very happy to welcome Mark Stanislav, Security Evangelist at Duo Security. Mark has a long history of working in the IT security field. He focuses primarily on Linux architecture, information security, and web application development. Mark earned his bachelor’s degree in networking and IT administration and his master of science in technical studies based on information assurance. Mark also holds a CISFP, security, Linux and CCSK certification.

Joining Mark will be our own Farooq Ahmed, Software Development Manager at Online Tech. Farooq has made a career out of creating and implementing secure and well-performing applications and has a wealth of hands-on, real-life experience in the trenches and Farooq is going to speak to the Windows platform and give us some best practices for how to implement encryption on the Windows platform. Welcome Farooq, welcome, Mark.

Farooq: Hello, everyone.

Mark: Thank you!

April: Mark, we’re going to go ahead and let you kick off the presentation, here, and we also want to encourage everyone to share your questions and comments as we go. We often get some natural pauses when we can address them or we’ll hit them at the end of the webinar.

Mark: Great, well, we’ll get started here, then. Welcome, everyone. Cryptography, encryption, the whole thing is a pretty involved topic and it’s great to be able to take some time today just to go over some basics and then also get into the enterprise deployment of encryption. I think between Farooq and I, hopefully we’ll give you some information that maybe you hadn’t heard before, both in terms of how to deploy and when to deploy cryptography because it’s not always super cut and dry in terms of when and where to use it. We’ll get rolling in here.


Mark: Encryption itself, one misconception which you can see kind of at that second indented bullet point is encryption and encoding are actually two separate topics. So, what encryption gets at is having some sort of data, which we call plain text. When we’re talking about cryptography, that plain text we’re looking to change into ciphertext. Now, all that’s really coming down to is we want the date, when it comes out to the ciphertext point, to be unreadable by anyone, even if they know how we encrypted it. The real power of modern cryptography is even if you know how that cryptography works, we still want it to be stronger than just that knowledge. Really, when we talk about cryptography, a lot of times you’ll hear that the secret or the key is everything. In modern crypto systems, it really is a focus on that key should be the key to how things are encrypted.

The big point we should make here is that good cryptography, the things that you should be using in your enterprise, the algorithm how it works, should be open. It should be public. All the ciphers that we use that are regulated, the NIST, which is the government agency that kind of tells how to do federal information processing within standards, those are all open. Those are all free and those are widely available. The secret, the key, should be the thing that really ties that crypto system together with protecting your information.

As you can see on that second part about ciphertext, when we actually apply an algorithm and then take that key as an input into that algorithm with our plain text, we get out ciphertext and that’s kind of what we’re looking for in terms of encryption, what that does, and how that works. In terms of crypto, we’ll talk about a couple of big ideas in terms of cryptography in general, the first one being symmetric key crypto. All that means … if you hear the term symmetric, effectively what we’re saying is that it’s the same on both sides, right? There’s symmetry there.

In terms of symmetric key crypto, the most common application for something like this is you have a file you would like to encrypt. You want to give it a, let’s say a passphrase, password, right, on that file to protect it. In terms of a symmetric key crypto system, basically all we’re doing is saying, “Here is an algorithm that’s doing cryptography. Here’s my key,” and then you provide that file, let’s say via email. It’s encrypted, it’s safe, you can transmit it via email, no concerns, and then you can get on a phone call with your friend and say, “Hey the password for this is …” and then just tell them the 20-character password you’ve made up for this file. Symmetric key crypto is very fast and when we’re dealing with big pieces of data, we need to do symmetric key crypto. Otherwise, it would be kind of unfeasible, really, to do it on a daily basis if there wasn’t a symmetric key at work.

The very input on how symmetric key crypto works is pretty simple. The little diagram we have there. You have some data you want to encrypt. You pass that data through this cryptography cipher that, again, is now public knowledge, no big deal. You put in your secret key and then the result is the ciphertext. Now, starting from the ciphertext point of view, we take the ciphertext, put it back into our cipher in terms of the decryption. You had the encryption, now the decryption. You put the same key in again, a symmetric key, and you get out the plain text. So, the same key input yields the same key output when you do the encryption and decryption portion. Now, symmetric key crypto is one part of the equation.


Mark: The other, kind of, side of this if you’re kind of guessing at home, if you’re not aware already, is asymmetric key crypto. So, the keys are different, right? What this allows us to do and why this is extremely important to know about is when we’re working with crypto systems, symmetric, asymmetric, and so on, what we see often is actually this co-mingling of these two different types of things. If you heard of the RSA algorithm, for instance, that is actually an asymmetric cryptography standard. What happens is you actually have a key pair.

Instead of having one single key that you use for both encryption and decryption, this key pair allows us to do some pretty novel things where you can actually give out this public key, just publish it on the internet, no big deal. Someone can actually encrypt data they want to send to you with your public key. The nice part is the data they sent to you can only be read by this private key that you possess. We’ve kind of gotten past the whole part of, “I need to give you a phone call and send you this long password for this key.” It can just come down to you. I can send you this file over the internet plain text, no worries, no encryption. You can encrypt data to me, send it over, now secure, and I, being the person with the private key, can decrypt it.

It’s a very, very powerful shift in how we look at cryptography and where this comes into play a lot for most people is when you use things like the secure website you’re going to. You’re using SSL on that website. That standard and how that actually works, is it actually will do the asymmetric part. If you ever know about a website SSL certificate, for instance, you’re actually doing both asymmetric and symmetric cryptography by just using a simple, secure website.

That’s pretty interesting because what it lets us do is, when you go to a website, you actually establish a symmetric key by using the asymmetric cryptography we just talked about. You can actually transmit that symmetric key securely over the internet without ever having to call someone up and say, “Hey, this is my password for this session of our web transaction.” So, if you think about how the modern internet works and websites work, without the asymmetric cryptography, doing this securely would be a really big pain and pretty infeasible in most cases.

Interestingly enough, in different technologies, such as you’ll hear GPG or PGP, maybe, and we’ll talk about that briefly, this also involves having both asymmetric and symmetric cryptography. So just keep that in mind. Know the differences between the symmetric and asymmetric and we’ll kind of wrap that in a little bit later, here.


Mark: Another portion of this, and slightly different from what we’ve been talking about, which is encryption and decryption, right? Now, we’re talking about what’s known as a cryptographic hash. What the premise of this is, let’s say I have a file of data and I want to represent this file of data without giving, necessarily, all the data to some person on the internet, let’s say. Cryptographic hashes can actually take in a large amount of data and then actually output this fixed size. There’s a certain number of bytes on the input, maybe 1024 kilobytes, so a meg of data on the input, and on the output you actually get a very, very small representation of that data. Maybe in 20 bytes or so.

What’s interesting about this is if you’re looking for a verification of the file I have on this system is the exact same file I had on this system yesterday, if you actually take the cryptographic hash of that file at one point in time, save that, you can actually look at that file again, do the same cryptograph operation to figure out, “Here’s the hash of this file now,” compare the two, and what’s very interesting and really how a lot of these cryptographic hashes work … now, there’s something about … in terms of infinity of numbers and some other big, big number-type things, we shouldn’t really see what’s known as a collision.

So, if I generate a cryptographic hash of a file I have on my system and you do that on a file in your system, you really should never see, without probably making it very intentional trying to do so, see the same output hash on the other end. What that allows us to do is have this unique representation of data. Another part of this that’s quite interesting is if I give you a file and you change the letter A to B just somewhere in the middle of that file, the hash that you get out of your hashing function versus what I get out of the same hashing function with my file is probably going to look dramatically different.

Let’s say the hash value is 20 characters long. Within those 20 characters, if you even see any repetition at all, I would be surprised. It’s probably going to look entirely different. What’s nice about that is a value of a hash doesn’t change in a predictable way. It changes in a very unpredictable way, which is some of the security and strength of how those algorithms work. Where the input of something and the output of something … you can’t really make an inference of what that output will look like just with the input.

When we talk about things like storing passwords securely, depending on how tech-savvy you are and what you do in your particular field, if we store someone’s password with, you might hear MD5 or SHA1, some of these cryptographic hashing standards at a really fundamental level, not that that’s necessarily a really prudent thing to do all the time, but at a fundamental level, if I give you a password into a system and you get a hash out of that, you should have no idea what that password possibly is. Ideally, you should never be able to find another password that comes out to the same exact cryptographic hash as well.

There’s some really interesting properties at play, things that we and IT use every day. A lot of these things are kind of under the covers and we don’t get to bring them to light, necessarily. That’s why we really enjoy doing webinars like this to present some of these topics, so you maybe go, “Huh. That’s how that works on the underside of my software that I’m currently developing.” Which is, of course, good to note the other side of the equation.


Mark: As I touched on a little bit ago, cryptography in use, the most common one I think that we can talk about, again, is that SSL/TLS web standard. When you go to a website, type in HTTPS and you’re doing that secure communication between your browser and that web server, that’s using both the asymmetric and symmetric cryptography as well as some cryptographic hashing in terms of some of the things it does with SSL certificate, which is actually the part that is allowing you to have that secure communication.

Of course, web standards and browsers and all those things could be a whole other webinar that we should probably do one day, but just so you know, those things are at play on the background and it’s quite interesting to see the prevalence of that today in modern society. What would we be without secure websites for a lot of things? Other technologies where cryptography is heavily in use, if your company uses a virtual private network, you’re using cryptography to secure that traffic. If you’re doing, very common now, if you have a website, let’s say, you might hear SFTP: Secure File Transfer Protocol. SFTP is, again, using cryptography to secure that data.

Flash drive and hard drive security is getting more and more popular. Obviously, if you lose a flash drive in the back of a cab, you probably want to know that the data that you’ve lost, while it may not be in your possession, is still not in anyone else’s possession either, because it’s encrypted, and they can’t get to that data without your secret key. Bitcoins I think have been a really exciting thing to see. Cryptography has so rarely been so out there, I guess. Bitcoins and the whole market behind bitcoins, I’m sure some of you may even have some bitcoins, how that all works is really just a lot of cryptography in very unique applications and allows people to do things like trading this virtual currency and having a lot of interesting security built into that process.

One other thing that a lot of us maybe have done in the past or currently do … the idea of a digital signature. If you have, let’s say, an email, for instance, and you have a file attachment, you can actually do combining cryptographic hashing and that asymmetric, which is also, if it wasn’t implied on the slide, asymmetric is also sometimes known as public key cryptography. Utilizing public key cryptography and cryptographic hashing, you can actually say that that file attached to that email has not been changed since the person sent it to me. More than the fact that it hasn’t been changed, you can also say that, “I know it was Mark that sent it to me because only Mark has the private key that could possibly sign this attachment.”

So, a lot of big math, a lot of very technical details, and some brilliant people that have put these algorithms together over the years. When it comes down to it, we utilize this stuff every single day and it’s really revolutionized how we do information security.


Mark: It’s worth saying with as many things about cryptography as we can talk about here today and with as many technical pieces of how cryptography works, I wanted to kind of point out three big ideas and three big topics of where we want to make sure that the right information gets out to people. We would like to set some maybe false truths a little bit more right. One topic being, there is a misconception that if you or your friend or your company makes an encryption algorithm and you hide how that encryption algorithm works, that that will somehow be the most secure encryption, ever.

The reality is, as I mentioned at the start of the webinar, these cryptographic standards that we use every single day, things like AES and RSA, these have gone through just insane amounts of rigor. Most recently, the government had a competition, and by the government I mean the National Institute of Standard Technologies, which is really more of an academic portion of the government than anything, they put on a competition for what will be the cryptographic hashing standard going forward in the future. The competition itself lasted, I think, for about 10 years.

When we talk about security and really understanding and believing in the things that we put out there as, “These are standard,” if you can imagine anything else that takes 10 years other than maybe certain drugs that go to market, for instance, we as a security community and the academic community and industry and private organizations, all these different groups are putting so much focus on trying to break this cryptography, trying to understand how it works and defeat it, that by the time we get to market, if you will, with some of these things as standard, they have been just torn apart.

Really what comes is we get the cream of the crop. We get the best cryptography, the most functional, the fastest, and with the highest level of security. Don’t think that by making cryptography that’s secret, you’re somehow making more secure than people that have spent their lives, really, doing this as a profession and then spending 10 years with everyone from across the sea to locally here at home attacking this stuff and trying to break it. Be pretty confident in how that works.

Another thing that’s a big misconception is public key cryptography. This is one of those terms where it sounds like you are allowing anyone to basically decrypt your data. What public key cryptography, also again known as asymmetric cryptography, is saying is there is a public-private pair. The public part you can give to anyone and they will never be able to steal the data encrypted with that public key. Only the private key can actually decrypt it. If you hear, “Public key cryptography,” that’s not a bad thing. That’s not an insecure way to do things. It’s just a more common phrase for this thing we call asymmetric cryptography.

The last one, I think no more timely than with all this news about PRISM and all this other interesting stuff happening, in terms of the government, back doors in cryptography and all that other stuff. This is one of those things that sounds exciting and sounds scary. If you happen to know that the government is doing this, please tell someone but aside from that, again, these algorithms that we all use have been under huge amounts of scrutiny, peer reviews from not just our nation but nations all around the world. In terms of cryptography, unless someone comes out with some earth-shattering, ground-breaking news, you should feel confident in using cryptography to protect yourself from competitors, governments, whatever your risk is or threat is as an industry or a person in IT.

You should believe in it until there’s some really, really hefty evidence otherwise. Don’t worry too much at night. You should be able to trust in this. A lot of this is based on math that even a millenial away we won’t be able to crack some of this math we’re currently using without some really big revolutions. Those are some things that you should hopefully feel a little better about if you have some concerns. For the next slide, we’ll actually have Farooq talk about kind of our scenario for this presentation and he’ll also get into, a little bit, some use cases of cryptography. Farooq?


Farooq: All right. Thanks for the info, Mark, and to put all this information into perspective, I think we should take a scenario. In our scenario right now, we are going to take an example of the hospital system that interacts with vendors. In our scenario, it’s an insurance company. There could be multiple vendors out there sending us data. Multiple types of data. We are not going into the detail of the data format because there is so much about it. Electronic health records are in many other standards and other formats we can discuss but this is out of the scope of this presentation. Basically, the data is coming in. It could be in XML format, I think, for this example. I’m going to fill in some details about it.

What these vendors do, they connect us to the internet via a VPN tunnel and send the patient data to an SSL website. We receive the data into our Linux system. Basically, they upload the files and it’s encrypted on our Linux server once it’s uploaded and then our application server will post that file, we are SFTP from that Linux server. We could have multiple services running in the background to pull those files, but then again this is the implementation detail. The application server decrypts the contents of those files and determines how we should store the data in the database. I’m going to discuss those in detail, exactly what to look for when you select the data for decryption. Sometimes you want to decrypt the whole database. Sometimes it’s not feasible because of the size of the data and because of performance of the application, so you would want to select only a few fields that you want to encrypt.

Then, again, this application server is a website that doctors and patients can exit and view the patient information via the SSL. This is our scenario and in the next slide we present the diagram. On the upper left-hand side, we have the insurance company talking to our Linux server, sending the files over. Then in the blue box we have the Windows App server getting the file from the Linux server and sending it to the database. This is the scenario that we’re going to take and discuss it further. Mark, can you explain the VPN and SSL?


Mark: Sure, absolutely. One thing that’s great to touch on, I think, is sometimes when you say, “I’m using encryption,” we use that a little bit more as a blanket statement than maybe we should. A lot of you, again, may have a VPN connection to your work, your office, what have you. The thing to remember about a VPN is, generally speaking, now there are some exceptions, but generally speaking, the purpose of a VPN is to connect one network to another network. Let’s say you’re at home. Your home network may then connect to your work network. Then, whether you’re on your laptop or your desktop at home, you can get access to the server you need at work.

When we’re talking about using encryption and protecting data and data transfer, it’s important to remember that if you’re transferring data, let’s say to a website over a VPN, if you’re transmitting that data in the clear, in a clear text format, if you will, that data actually is going to be in a place where it could be looked at or viewed by anyone on your network or on the other side of the network when it gets to your work network. What the recommendation would be is, don’t just use the VPN and go, “Oh, everything is secure because I have a VPN.” We would actually recommend you use a secure website on the other side of that VPN.

What you’re doing then, effectively, is you’re communicating your laptop, let’s say, over to that web server over the VPN but the actual connection between your laptop and the web server is now secure. Even if there are attackers on your home network or on the work network that could have otherwise gotten access, you’re actually blocking that path using encryption between you and that web server. It’s good to think about the threat. It’s good to think about the bigger picture of how do we secure data and not just kind of go, “Well, we’re using encryption, so everything’s encrypted.” The reality is levels of security in general have a certain scope of what it protects and how it protects.

It’s important to think about things in a bigger idea and kind of doing those threat-modeling exercises. Where else could this data be looked at? How else could someone see this data while it’s transmitting from my laptop over the VPN? This is a good exercise to go through in general security overall.

So, getting back to this idea and just to kind of visualize this a little bit better. Essentially, this insurance company which is our vendor in this scenario, this insurance company will actually be sending us this uploaded data file to a web server we have on our hospital network. Again, this comes over a VPN and SSL, so the VPN for the network and then the SSL for the actual website transaction. When this comes down to us in the web server, the file itself isn’t encrypted, but the entire path to us is encrypted. Not just in a site-to-site way, but also a file-server connection between our, let’s say, laptop, again, and this web server. So that’s great. We can go to the next slide on encrypting files.

Mark: In terms of encryption and files in general, just to kind of preview next week, we’ll actually have a bit of a talk on some bigger ideas on volume encryption and SAN encryption, some of these bigger topics about data encryption. At a file-specific level, if we look at a Linux server in general, the two big things that usually are utilized by people for file encryption are one being GPG. Now, GPG, some of you may have heard of PGP, which is a long-existing standard for this data encryption. GPG is actually this implementation of an open standard.

So, whereas PGP was kind of well, I guess we can say commercial standard, if you will, GPG is this free implementation of this open standard. Just like we were talking about how SSL secure websites work, it actually uses both symmetric and asymmetric cryptography so that and not to get into too many of the technicals on this event, but basically you can have your own key pair as an individual. You can send over your public key portion to someone. They can encrypt the file. You can download that encrypted file and you, as the owner of that key, can then decrypt it. It basically just adds a little bit more process and a little bit more structure to this operation of, “I want to give a file to my friend that’s encrypted and make sure they can decrypt it.”

At a broader level, a much broader level, there’s this thing called open SSL which I think Farooq will touch on as well. Open SSL is a hugely popular, very standard set of crypto implementations, effectively. What’s neat is, on a Linux system, pretty much out of the box in most cases, we actually have a command line utility that we can very, very easily encrypt, decrypt, do digital signatures, all these cryptographic things we would want to do on a daily basis, you can actually do that with a couple just command lines, flags, and parameters and actually encrypt and decrypt files using all the standard, well-trusted algorithms that everyone else would be using anyways.

That’s very powerful because if you think about, “Well, I want to do cryptography, I want to encrypt files before I send them, but I really don’t have the technology. I don’t want to buy a product.” The nice part is, again, this is all open, public knowledge and if you just have a Linux box sitting around, type “open SSL” at some point and you’ll probably see that that’s actually on your system right now and very powerful to use.

Let me pull this up. It’s easy to say, “Oh, this is just a quick thing you can do on your own Linux system at home and it doesn’t cost you anything.” I actually want to show you just a quick visual example. Effectively, this is just output coming out of my Linux terminal that I was running at home. Just a couple things. We’ll kind of go a little step-by-step here. Open SSL is the command. That first line you see. Open SSL-ENC. That just stands for encryption. The –E is actually saying, “Encrypt the file.” The next part is kind of the weird part and a little bit more in depth than we need to go on this conversation but basically, AES, as I have mentioned, is very common; the one the government recommends in all the standards. AES is a symmetric key cryptography algorithm.

If you want to do that kind of cryptography where you have this one key, if you want to let someone else decrypt it, you kind of just tell them what it is or give it to them securely some other way. After saying how we want to do that cryptography, we just give it a file name of what we want to encrypt and we give an output of what the file should be called after it’s encrypted. That literal line is all you need to do to encrypt a file on a Linux system. Of course, the opposite of that is how do we decrypt that. Always good to know, as well.

As you can kind of see in the difference of the command line options, you basically just change one little flag to D for decrypt instead of E for encrypt, say what file you’re decrypting, and then what the file name should be after you decrypt it. Very simple, very quick to use. The next time you want to send a file to your friend and encrypt it, if you have a Linux server sitting around, just type these commands in, send it over email, because, again, it’s all encrypted already, and just call them up and say, “Hey, the password is …” and give to them, obviously a pretty nice-sized password so it’s secure still.

It’s a very simple operation and you don’t have to pay for anything, which is something I think a lot of people miss out on. Then, there’s some just additional notes there about AES and keys and whatnot. Obviously, the topic of cryptography is very involved, very complex. What we want to do is operationalize your knowledge so that you feel comfortable knowing what these terms mean and kind of how to get started with some of these issues if you haven’t had a chance to kind of really step into this beyond just kind of every day end-user type of usage of cryptography.


Mark: What we end up with is we’ve already transmitted this file securely; it’s gotten to our web server, and let’s just say we used open SSL to encrypt this file. It’s already on our web server, we ran kind of the same thing we just showed you on how to encrypt a file. Now, this file is no longer plain text, it’s ciphertext, right? What we’re at a point of is now that this file has been encrypted, we could send it via email, we could put it on a thumb drive, we could send it to any website and upload it. We have to trust, then, that as long as the passphrase or the key that we have for that file and how its encrypted as long as that’s strong enough, we should be able to reasonably trust in how that cryptography is built, that no one will be able to break that data and get back the plain text out of that ciphertext.

That’s where the power starts coming in and kind of where we start leading into what Farooq will do with that. What’s nice to know is now that that file’s been encrypted, even though it was encrypted in transit before, so going from one point to the other it was secure, but that data sitting on your Linux server was still insecure when it ended up there. Now we’ve made that data on the Linux server secure. Even if someone broke into that Linux server, unless they have the key, they still won’t be able to do anything with that data other than stare at it and get angry. Which is what we always want to do to an attacker, right? Make them frustrated. I think there’s an animation there for you coming up.


Mark: After this file’s been encrypted, what we’re going to do next, and this is a little bit of, I guess, overkill if you want to think of it that way or double security, there’s a lot of kind of phrases we could toss out there. The file is already encrypted, which is great. We’re actually going to transfer this file securely, though, between our Linux web server and our Windows application server. Now, reasonably, again, there’s really no reason that we should be worried about this but what’s important to think about when you’re using cryptography is in most cases, doing this cryptography is kind of, to the end user, no big deal. There’s really no extra effort as long as you have a client and a server that speak cryptography properly, you really don’t have to worry about how this is all working on the backside and it’s a good practice to get into to, when in doubt or when you’re not sure or just in case, use cryptography like with SFTP.

A lot of you on this call may have been using computers for a lot of years, probably have ran into FTP, right? File Transfer Protocol. If you’re still using FTP to upload, download data, I’d really, really recommend you stop that for two reasons. One, when you do FTP in the normal form, you’re actually transmitting not only the data insecurely, that it could be read by anyone else that’s able to intercept that data as it traverses the internet or network, but also the login credentials that you’re logging into the FTP server itself are actually also clear text or plain text. There’s no security for your credentials and there’s no security for your data.

When you use SFTP, you have security for both. If you’re still using FTP, please, please switch over to SFTP. One minor thing to point out, FTP and SFTP, despite the names, are actually very different things. They’re not based off the same standards. They’re actually completely different technologies, just a kind of a slight difference there to point out. What I’m going to do now is give it back over to Farooq and now that we have this encrypted data and we have it over to this web application server, he’s actually going to talk about what do we do with that data? How do we store that data long-term? How do we interact with that data? So, Farooq, it’s all yours.


April: I’m going to hijack us here for a quick second to ask a relevant question to VPN and SFTP. Can you talk a little bit about the advantage of a VPN and SSL connection over using just SSH or explain a little bit about why you chose one over the other at different points in the scenario?

Mark: Sure, sure. I’ll try to answer that the best I can. In terms of, again, getting back to this idea of cryptography in general and when to use it, how to use it, which a lot of this conversation is about, a VPN is great because all traffic that goes from a computer with a VPN attached to this other end point, so, again, like your work network and your home, all that communication flowing through is now secure. It’s going over the internet but it’s actually still secure. If we’re going to talk about things like SFTP and SSL, why would we still necessarily use those? The network on the other side, the work network, and the network on your side, your home network, we don’t necessarily know that the other computers on that network aren’t listening or haven’t been compromised.

By transmitting data securely with something like SFTP or SSL, which is kind of a point-to-point, computer-to-computer conversation, we can actually ensure a kind of safe transit of that data between that one computer and the other computer. Now, of course we like to think that our home network is secure and our work network is secure but really what we should try to do is, at any point possible, layer in security because anytime we trust on one certain technology or one certain application of a security control, unfortunately, it only takes one control to be broken by an attacker or otherwise manipulated. By layering our security controls, by layering how we’re doing the security, we can actually help ensure that the data we’re trying to upload will actually end up there securely, not manipulated, not stolen or otherwise.

Now, of course, we also have the opportunity to kind of double back on that. You could just use SSL from your home computer to your work network. You could use SFTP from your home computer to your work network and you don’t necessarily need a VPN. Really, the purpose of a VPN is kind of twofold, usually. One is, for all the network conversations you’re having over the internet to your work network, a lot of standards don’t have encryption built in. A lot of standards don’t natively speak cryptography. For all of those things that don’t natively speak, like SSL and SFTP, we need a way to transmit that data securely nonetheless.

The other point is, over a VPN, you basically build this trust relationship where servers on your work network aren’t exposed to the internet but by making this VPN connection, you can actually expose these servers that would otherwise be hidden on the internet, to your home network, now. You’ve actually traversed one network and gone to a second network. You just happened to use the internet to make that traversal happen. You can layer security is one answer and the other answer is, for things that don’t natively have security, by using a VPN you can actually add that across the board.

April: That’s great, Mark, thanks very much. That makes sense.

Mark: Absolutely.


Farooq: Now, we’re going to talk about the software implementation of this whole cryptography thing. Before I discuss what’s written on this slide, I just want to quickly tell you about the SFTP software even though Mark already talked about downloading the SFTP files, downloading the files from the Linux server using the SFTP. You can implement it in the application software in multiple ways. You can download a client. A lot of SFTP clients available freely on the internet. You can download the files using the SFTP or you can even write your own .net application to download those files periodically.

There is a SharpSSH library available free. You can Google Tamir or SharpSSH to download its source ports. It’s a good piece of software if you want to implement it or automate this piece of download. Let’s discuss these things, decrypting the files on Windows. We have files downloaded from Linux onto the Windows server. Now, we want to decrypt them. I’m going to restrict myself to those two technologies that he discussed, GPG and open SSL. Both of these you can implement in .net easily. GPG is available from the new PG.org. You can download and install this package. This is a command-like tool. You basically are going to have to implement it as an external process and invoke it using your .net library.

Again, there are multiple ready-made solutions available as a wrapper on top of those command lines. If you don’t have time to write that code, you can download those wrappers and implement it or you can write your own wrapper. Obviously, when you write your own wrapper you can implement some of the exception handling in your code and integrate it with your code. Open SSL can also be implemented at .net and you can download it from source ports again, openSSL-net. / sourceports.net. This is a natively written C# DLL so you don’t really have to invoke an external process like the GPG. Instead, you can call these methods out of those libraries and have better performance. Obviously, because it’s native, you can integrate it with your code easily, you can do a lot better exception handling than GPG, it’s going to be faster, and performance is definitely going to be better with open SSL.


Farooq: So, that was about decrypting the files. The encryption support. Once you have the file downloaded to your Windows environment, you may want to extract the data from that file and then encrypt some of the data and put it in the database. Briefly, I’m going to talk about the encryption support in .net. We have this library that’s system.security.cryptography that comes with the .net and it has all the things that you could ask for, for crypto. It’s got symmetrical algorithms, asymmetrical algorithms, and then hashing algorithms, anything that you need. Obviously, this is built by Microsoft so it has its own exception handling.

I emphasize a lot about exception handling so you can write your code better, catch those exceptions when needed, and make your application as user-friendly as possible. Again, system.security.cryptgraphy. This is a managed code which means that you don’t have to invoke any processes outside of your application environment and performance is going to be a lot better. Because this cryptography library has a lot of algorithms, symmetric, asymmetric, and hashing algorithms, the question is, “What do you use to encrypt your data just to put it in the database?” I guess the answer is dependent on your data, how you want to decrypt it, what information you want to encrypt.

If you’re decrypting anything, do you need to bring it back and decrypt it to display it someplace? If you want to do that, then you obviously will do symmetric or asymmetric encryption but you won’t do hashing. Obviously, you would want to do symmetric encryption in this scenario especially because you are not exchanging the data with anyone else. It’s just going into the database and coming back. The connection between the database and the application server is most probably a secure connection. You don’t really have to go with the multiple keys or public-private key. You can just use a single-key solution, which is best and faster in this scenario, first of all.


Farooq: All right, so the database encryption versus the data encryption. What I mean by that is that instead of selecting data, you can just encrypt the whole database. It is really easy to implement. It’s faster to implement to encrypt the whole database, but it is very resource intensive. In SQL server 2008, the way it is implemented, when the whole database is encrypted, the whole database needs to be decrypted before you can access the database or you can query the database. In a lot of cases, this is not practical but if it is a requirement, then it is a requirement, you have to do that. I would say that for the small-sized database it is pretty good, but if your database is large, it could be a very, very slow process.

Now, the data encryption in most of the cases, the whole database encryption doesn’t work so you should go back to your data encryption, which means that you are only encrypting part of the data. Not the whole database itself. Obviously, it takes a little preparation because you need to understand what it is you want to encrypt. What part of the data you want to encrypt. I’ll just get the best practices that select what data you want to encrypt and then if you’re doing only part of the data encryption then it will definitely give you better performance as compared to the whole database encryption.


Farooq: The data encryption. Once you’ve decided that you’re not going to do the whole database encryption but just part of the data, you can implement it at multiple levels. You can implement it at the database level. I know for sure that with SQL server 2008 you can encrypt part of the data, you can encrypt part of the table, and it’s not that hard to do. There is one disadvantage. Query when you write a query as total procedure or a function, you have to write the whole encryption algorithm with that database. There is a way around.

You can write your own function and call those functions but again, exception handling is still going to be a problem when you do it in the SQL server because SQL server, especially Microsoft SQL server is notorious for not a good exception handler. If you don’t want to do it the database level, you can do it at the .net level, which is your application … if you’re writing your application in .net. Again, it doesn’t matter if you’re writing your application in C# or VB.net the whole framework provides you the same functionality independent of the language. Write the whole framework. You can integrate it with your current business logic layer or data layer, data access layer, and obviously you can also integrate it with your exception handling framework.

You can integrate it with your database easily. It’s going to give you a lot better performance than the database and it’ll be a lot easier to maintain. Another thing that you can do when you do this, when you implement it in .net, you can separate your encryption-decryption code into a whole new project, a whole new library and give your team limited access to your own encryption libraries, algorithms, and keys.


Farooq: Okay, so what to encrypt. I’ve been talking about instead of doing the whole database, we want to do part of the database and obviously only we want to do that because we want better performance. Data selection is a careful process. Again, defense on your case and on your business … you have to analyze the data that you want to encrypt. Part of the data that can be sensitive for one application or one business may not be as sensitive for another business. We are hospital. Our example is the hospital so a lot of data is going to be sensitive.

An example is the username and password. No matter what kind of a business you’re running, a username and password is always sensitive information, for people’s login credentials. In this scenario, you may even want to use a hashing algorithm for username and password, not even a symmetrical algorithm because you never need to get the username and password back and display it anywhere. That’s not a good practice. You can always hash the user-provided username and password and compare it whatever is stored in the database. That’s one.

Social security number, other IDs, credit card numbers, those are sensitive information. You need to always encrypt them and put the encrypted copy in the database. Another example is the address, phone numbers, emails. Those are the things that could be sensitive to, again, to some businesses. To some business they may not be as sensitive. It’s your choice. Whatever you want to do with those data; you can store them as plain text or you can encrypt them if you need to. Images. Images is a big topic. Again, it depends on what your need is. You can encrypt images. The other thing that you need to worry about with the images, if you want to store them in the database or on the file system. No matter what you do, encryption will apply to those images equally.


Farooq: Securing your code and keys. Now that you know what you’re going to do with your data, how you’re going to encrypt it, you also need to worry about the key management. In our example, our application is interacting with the database so you don’t really have to worry about the key management in our case. It’s just a private key. You are not sharing the data so you do not need to ship your key to anyone for decryption. It is your key. You secure it in your code. You can hardcode it in your code, the key, or you can store it somewhere on the file system securely.

You can also acquire a hardware security module for your key management. It’s going to be a little costly but a lot of those key management modules are. They come with the API and you can implement those APIs in the .net. Interacting with those hardware modules is very easy in .net. The other thing that you can use is a key server. An online key server. That’s also a solution if you want to manage your key that way. If you’re doing .net development, you know that .net code or .net DLL is just an intermediate code. It’s not a full compiled assembly. It’s not a machine code and people can still disassemble this code using the normal ILDASM which comes with the .net and Microsoft tools. You can use that.

To avoid the accidental disassembler, you can use an obfuscator. Obfuscator basically just jumbles your code and take away some of the information that’s not really necessary to run your library or run your application and it just makes it a little harder for other people to disassemble your application. One of them comes with the .net in Microsoft you can use that but it’s very easy to break in. There are some third-party obfuscators available ranging from a few hundred bucks to a few thousand bucks. You can use those to obfuscate your code and it’s a very, very easy process. That’s all about the software layer that we can discuss in good end-design.


April: Great. Well, Mark, Farooq, that was a fantastic download. I know we threw a ton of information out there. We have a very long list of excellent questions. We’re going to touch on a couple of them here as our time allows. I know that Mark and Farooq have other things they need to get to. Those that we can’t get to live during the webinar, we’ll make sure to follow up with Mark and Farooq and get some answers back to you. Don’t despair if we can’t get to your specific question today. Let’s see here. Is it advisable to have different key pairs for each user that will store encrypted data?

Mark: That’s a great question. I guess we can frame a little bit of context. Let’s say we’re just a company and then each of the employees at a company want to encrypt data and send it around to different people, for instance. A couple ways to do that. One thing we always have to remember when we deal with cryptography, especially at the enterprise level, is that if your employee leaves the company and for lack of a better phrase they hold the keys to the kingdom for some of the data at your company, that can cause quite a bit of a problem.

Just keep in consideration when you’re doing cryptography at a company at the enterprise level, the idea of key escrow so that you as an organization have access to the keys that could decrypt that data if an employee were to, unfortunately, have an accident and couldn’t tell it to you or they decide to leave the company on bad terms. Whatever the case is, keep that in mind. At a per-user level, if you can orchestrate that, that is best way to go because if you can trust that the person who has that specific private key pair, or public-private key pair, that lets them do things like sign email from them and say, “This email came from me.” Or encrypt files so that only … or, I should say digitally sign an encrypted file to say, “I encrypted this file. This is coming from me, Mark.”

The other side of that is if you want to send data to me, you can actually use my public key, send it to me and only I will be able to decrypt it. If you can manage the key management part of this equation, it actually adds a lot of both privacy and security concerns for that employee transmitting and sending data or receiving data kind of on a one-to-one level with other people. There’s a lot of upside to that, yes.

April: Great, thanks, Mark. I’m going to address several questions here which ask about the specific requirements of the HIPAA privacy and security rule regarding encryption. I am certainly not the source of authority but we are actually looking at putting together a webinar that does address these questions specifically in a few weeks. Stay tuned for those details and the short answer is that the HIPAA Privacy and Security Rule does not specify any specific length of key or requirement around encryption. It doesn’t even necessarily require encryption although it has been highly, highly recommended to use it where appropriate because it can do so much to protect sensitive information.

Really, the key, speaking from hearing Leon Rodriguez and other members of HHS, is that they want to see that you have done a thorough risk analysis plan, to Farooq’s point, making sure that you have looked at your data and made reasonable, diligent decisions about what to encrypt and how to encrypt it. We’re going to actually put together a webinar to address some of those specific questions to the HIPAA Privacy and Security Rule. Let me choose one more technical question, here, while we have Mark and Farooq, and then we’ll circle back to the other ones as well.

Let’s talk about this one on key management. “I have hundreds of customers and am considering having a public key and private key pair for each customer.” Are there some good strategies there, Mark? You may have some good background to share with us about how to manage all those keys.

Mark: Yeah. I don’t know if we have the context but just as a example in the same, I hope the same way the person was asking the question. A company I previously worked for, we actually had done a similar deployment where each customer had its own public-private key pair. What we would actually do is we would take backups of their data and when we took that backup of their data, we would encrypt it with their public key. We would store their private keys way, way off site, not on the same server, not on the same network, even.

What that would allow us to do, if there was a disaster recovery scenario or there was a scenario where they wanted to validate that the configuration on one of their routers hadn’t changed without their knowledge, for instance, what we could do was actually then use that private key, pull the data off that server, decrypt it, and then compare the existing and the previous that we had saved. By doing it that way, what you do is limit scope for the actual potential compromise. If you had one private-public key pair for all of your customers, for example, if that one got stolen, now all of your customers’ data has been compromised.

Kind of in the same idea of segmentation of data on those kind of properties, we’re minimizing or at lease reducing the scope of risk for one single compromised key. In terms of managing that, that can definitely have some hefty overhead. Now, things like Microsoft certificate services, they have some pretty neat stuff built in to manage key pairs, certificates, and the alike. So, if you’re a Microsoft house that may be a good way to look at it.

Certainly, most things in cryptography come down to, “How do we securely store the private keys for all of the data?” As Farooq mentioned, hardware security modules is a great way to do that. There’s even network-based HSMs now that you can actually have one appliance on the network that manages those kinds of operations for your entire infrastructure. Unfortunately, it’s not really much of a one-size-fits-all. There’s a lot of contextual things that fall into that but I hope that at least brought up some of the underlying issue of what that question was for.


April: Thanks, Mark. One last question here that Farooq can address. Can you talk more about where to store the key when using it to encrypt data via the DAL? If someone has access to your server, wouldn’t they have free access to everything? And Farooq, what is a DAL?

Farooq: That’s a data access layer. A very good question and it’s related to what Mark just discussed that obviously if they have access to your server they have access to pretty much everything. To work your way around it is to really use the hardware security module. Like Mark mentioned, there are some network devices available where you can store your key. All of those devices come, pretty much all of them, comes with the API so you can interface easily with the .net and request a key when needed instead of saving it on the DLL, of course. DAL is not the efficient way or the ideal way but sometimes the resources limit us to store them on the same server.

Even if you do that, you still have two-server architecture or multiple server architecture. The key could be stored on the application server instead of the database server so you still have a little bit of separation between the data and the key. Again, it’s not ideal, but in some situations that would be our only option.

April: All right, well, Farooq, Mark, thank you so much and thanks everyone for joining us. I apologize for those of you who asked questions we didn’t have time to get to live but we will follow up with you and get you as many answers as we can, following the webinar. We’ll send everyone a link to this recording. If you have more questions about encryption, we’re going to address how to do that at the storage level next week, Tuesday at 2:00, and we look forward to seeing you there. Thanks everyone.


Mark StanislavMark Stanislav, Security Evangelist, Duo Security
Mark Stanislav is the Security Evangelist for Duo Security, an Ann Arbor-based startup focused on two-factor authentication and mobile security. With a career spanning over a decade, Mark has worked within small business, academia, startup, and corporate environments, primarily focused on Linux architecture, information security, and web application development.

Mark earned his Bachelor of Science Degree in Networking & IT Administration and his Master of Science Degree in Technology Studies, focused on Information Assurance, both from Eastern Michigan University. Mark also holds his CISSP, Security+, Linux+, and CCSK certifications.


Farooq AhmedFarooq Ahmed, Software Development Manager, Online Tech
Farooq Ahmed is Online Tech’s Software Development Manager and is the Chief Architect of OTPortal, Online Tech’s feature-rich dashboard which delivers on-demand access to server monitoring, management and customer support 24x7.

His career spans more than 14 years with analysis, design and .Net development with VB.Net and C#. Farooq has designed components for online payment systems and the banking industry. Farooq earned a Master’s in Computer Science from the University of Karachi.

Webinars    |   @ Online
 

HIPAA Compliant Data Centers

By outsourcing our data center, we have increased our revenue generating capability and ROI. I can reassign staff to provide faster responses to end user issues and develop faster, more complex solutions.

- Erik Yochum, Director of IT, MMP

Have Questions?
Call Today 1-734-213-2020

live-chatemail-us

Live Chat
Events 0