Encrypting Data - CompTIA Security SY0-701 - 1.4

If you need to protect data that you're storing on an SSD, a hard drive, or any other type of storage device, then you'll need to work on encrypting all of this stored data. Sometimes you'll hear this referred to as encrypting data at rest. This includes not just individual files that you might have on these storage devices, but in some cases, everything that's on the storage devices using full disk or volume-level encryption.

In the Windows operating system, you may be using BitLocker to accomplish this. If you're using macOS, you may be using FileVault, and other operating systems have different ways of encrypting everything on a single volume. You might also need to encrypt a single file that is on a system and not the entire volume.

In Windows, you can use EFS, which stands for the Encrypting File System. It's a file-level encryption that's built into the NTFS file system. If you're using macOS, Linux, or even Windows, there are many third-party utilities that can perform a similar function.

In Windows, you would look at the properties of a file or folder, and inside the advanced attributes, you can select "Encrypt contents to secure data. " To enable EFS, a lot of the data that we use online is stored in a database, and of course, there are different techniques to protect the data that's inside of these database files. For example, you may be able to configure transparent encryption.

This uses a symmetric key to encrypt everything that might be in that database, and you would need to perform an encryption or decryption of that data each time the information is pulled from the database. Some of the information in your database might not be private or sensitive, so you might have some data inside the database that is protected or encrypted and other data which is still available in plain text. Here's an example of a table inside of a database: this is an employee database that has employee ID numbers, first names, last names, and Social Security numbers.

Of course, you could encrypt the entire database by applying a symmetric key so that all of this data is now encrypted. You can see we have no idea what part of this may have anything to do with an employee's name, their ID number, or their Social Security number. However, there's overhead involved in being able to view this information, and every time we need to search through the entire database, we would effectively need to decrypt all of the data within that single database.

One way to avoid some of that overhead is to only encrypt a certain type of data in the database. In this example, we're performing column-level encryption, where the employee ID, the first name, and the last name are all displayed in plain text. If you needed to search for a name or search for an ID, you can perform this very quickly without having to decrypt any other type of data.

But if you needed access to a person's Social Security number, you would either need to decrypt the entire column or that single record to be able to gain access to that data. Another common place to perform this encryption is when we're sending data across the network. We want to be sure that everything we're sending between two devices is protected, and if someone does tap into this connection and view that data, they wouldn't be able to make sense of any of those details.

For example, you're probably using a browser right now to watch this video, and all of the communication that's taking place in your browser is most likely using HTTPS, which means that everything traversing the network is encrypted. If you need to connect different sites to each other or need to connect individuals for remote access, we commonly would use a VPN to provide this encryption. This stands for Virtual Private Network, and it effectively creates an encrypted tunnel where you can send all information into the tunnel to the other side, and anything within that tunnel is going to be encrypted.

This is commonly used with client-based VPNs using SSL or TLS, and if you're connecting two sites together, we commonly use IPsec to provide that VPN connectivity. To have successful encryption and decryption, both sides must be using the same encryption algorithms. This is the formula that's used to not only provide the encryption process but also provides you with the way to decrypt that data on the other side.

Generally, both sides would agree from the very beginning to use one or more encryption algorithms so that both sides know exactly what to expect when information is received. Many times, the end user doesn't see the details of the algorithms that are being used, but they know that they're using a particular application, and they want to be sure that the person on the other side is using a similar application so that the encryption and decryption processes will be compatible. There are obviously advantages and disadvantages depending on what encryption algorithm you're using.

Some algorithms have a better security level, some work faster than others, and some have a more complex method for implementation. But once both sides agree on the application that will be used for encryption and decryption, everything else generally takes care of itself automatically. Usually, the security administrator will have a pretty good idea of what the requirements are for the users, and they'll make sure that the proper encryption algorithms are used.

Here's a good example of why it's so important that both parties in a conversation are using the same encryption algorithm. These are very broad comparisons between the Data Encryption Standard (DES) and the Advanced Encryption Standard (AES). You do not need to know the specifics of these block diagrams for the Security Plus exam, but you can visually see that there are quite a few differences between both of these algorithms.

The Data Encryption Standard (DES) has five different steps, which include breaking up the data into a left plaintext and right plaintext to finally come up with a 64-bit ciphertext. You can see that AES works a little bit differently, where you take a plaintext and a secret key, add it to a cipher, and finally get the ciphertext. There are also different versions of AES that can produce different levels of output.

You obviously would not be able to encrypt with DES and somehow decrypt with AES; you have to be sure that you're using compatible encryption and decryption algorithms on both sides of the conversation. Here's another interesting part about encryption algorithms: we know exactly how they work. The algorithms themselves are usually public; you can read the code or look through the math and see exactly the process that occurs.

The algorithm is usually a very well-known thing; in fact, it makes the algorithm more trustworthy because we can see the math and the process that's used to create the encryption. The one major piece of information that we don't have is the key, and although we know how the algorithm works, we still are not able to reverse engineer anything unless we have that key. This is very similar to the way that a door lock operates.

We know how door locks work; we know how to manufacture door locks; we know what happens inside of a door lock when you put a key in. But just knowing that information doesn't somehow allow you access through a locked door; you have to have the proper key, just as you do with encryption and decryption. That key helps determine the final output; if you're encrypting data, hashing data, or creating a digital signature, it's all based around that key.

And even though we have the algorithm and understand everything about the math, you still need the key to be able to gain access to the data. This is why we always tell you to keep those private keys private. If somebody gains access to your key, they're able to use it on your door lock, and now they have access to all of your data.

Like anything else, your encryption and decryption keys are subject to brute force attacks, which means that an attacker could go through every possible permutation to be able to determine what a public or private key might be. We can effectively prevent these brute force attacks from being successful by creating a very, very long key. In the world of encryption, a symmetric key of 128 bits or larger would be very common and, today, would be very protected.

As time goes on and our processors become more powerful and we're able to tie many different processors together, we may increase the size of our keys to make them that much more difficult to brute force. This extension of the key lengths also applies to asymmetric encryption as well. Even though an asymmetric key involves complex mathematics surrounding very large prime numbers, an attacker can still perform a brute force attack, and it's not uncommon to see asymmetric keys that have a key length of 372 bits or even larger.

This means that as time goes on, we may have to create larger and larger keys just to keep up with the changes in technology. But there are some other things we can do to make our existing keys that much more secure, and one of the ways to do that is to perform the encryption process multiple times on the same type of data. For example, you may want to hash a password, then hash the hash of that password, then hash the hash of the hash of that password, and so on.

This is referred to as key stretching or key strengthening. This means if someone wanted to brute force some data that's been encrypted multiple times using this key stretching method, they would need to decrypt multiple times to see if their brute force was successful, and this adds an additional overhead and certainly would create more time during the brute force process.