ℹ️DATA AT REST - BASIC ENCRYPTIONℹ️

[eb303623]

In this chapter, I will talk about data-at-rest. Data-at rest is the information that is stored on your computer’s hard drive or on removable media when it is not being used or transmitted, which is most of the time. In the event your computer is lost or stolen, accessed by an unauthorized person, or malware is scraping your personal files, encryption will prevent any information from being compromised. This chapter will cover some basics of encryption, encryption programs, and best
practices for effective employment of encryption. Let’s go.

WHAT IS ENCRYPTION?​

Encryption is the process of converting human-readable data, called plaintext, into a form that a human cannot read, and this is called ciphertext. This allows you to store or transfer data in unreadable form, because of that information remains confidential and private.

Encrypting sensitive data is one of the single most important steps users can take in the interest of securing sensitive personal information. Unfortunately, it is also
something that many users seem very hesitant to do. To the uninitiated it seems like a lot of work and may even seem to be a sign of paranoia. Though encryption does require a very minor shift in how users think about their data, it isn’t a great deal of work to set up initially. After it is installed and running it is almost
completely transparent to the user.

With the help of encryption, the following information security states are provided:
1. Privacy – encryption is used to hide information from unauthorized users during transmission or storage.
2. Integrity – encryption is used to prevent information from changing during transmission or storage.
3. Identifiability – encryption is used to authenticate the source of information and to prevent the sender from rejecting the fact that the data was sent by him.

in Order to read the encrypted information, the receiving party needs to have a key and a decoder (a device that implements the decryption algorithm).

Before we move into the specifics of encryption programs it is important to discuss the two broad categories of encryption that are used to protect data stored on a
computer. They are file-level and full-disk encryption. I believe that it is important to understand the benefits and limitations of each, and to use each where appropriate.

1. FILE-LEVEL ENCRYPTION​

File-level encryption allows you to create a file “container” that encrypts all the files within it. When you “close” the container, all the files within it are encrypted, restricting access to anyone who does not possess the correct password. This is perhaps the most commonly implemented type of
encryption employed by the average user. I use file-level encryption for some applications but consider it generally inferior to full-disk encryption.

2. FULL-DISK ENCRYPTION​

Full-disk encryption (FDE) offers the ultimate security for the data on a computer’s hard drive. Full-disk encryption means that the entire hard drive, including all files, the operating system, applications and programs, and anything else on there is encrypted when the computer is turned off. The only
portion of the hard drive that is left unencrypted is the boot loader, a very small portion that allows the computer to accept the entered password and begin the boot process upon startup.


Most users assume that file-level encryption is sufficient as long as all versions of sensitive files are encrypted. Unfortunately, this is fairly inaccurate. While using
your computer, it stores various versions of files such as saved “recovery” versions, records of filenames that you have accessed, internet browsing history, and a
great deal of other sensitive information, the majority of it without your permission or knowledge. If your computer is unencrypted, this information can be exploited to reveal sensitive information about you. This information may reveal the names, sizes, and even the contents of your most sensitive encrypted files. For example, if you edit a Microsoft Word document, it will automatically create an AutoSave version that can be recovered in the event your computer crashes or you accidentally close without saving. Unless you specifically change the location to which this file saves, it is written unencrypted to your hard drive in a nebulous
location that is not always easy for the average user to locate. Full-disk encryption prevents this kind of leakage from being accessed and exploited.

Encryption of the entire hard drive is beneficial for several other reasons. Full-disk encryption is the most transparent form of encryption. After the user initially
enters a password and the computer boots, it functions as it normally would. And
if your computer is lost or stolen, no information can be recovered from it. When a thief or attacker turns the device on a password prompt will appear, and the
computer will not boot up until the correct password is entered. If the hard drive is removed and plugged into another device as an external hard drive, or if the computer is booted with another operating system like a bootable DVD (two
common techniques to get around operating system passwords), all of the data on the computer will still be encrypted and inaccessible to the attacker.

Though some users possessing some familiarity with encryption consider full-disk encryption overkill, I firmly believe it should be the standard. Full-disk encryption
is the simplest form of encryption to use. Though setup may be a bit more daunting, the simplicity of its day-to-day use (especially in comparison to file-level encryption) far outweighs the hassle of encrypting it in the first place. Once installed and running, FDE only required a single password (when booting). It is
totally transparent from then on, and offers total protection whenever the device is powered down.

Users should also recognize there are downsides to everything, and FDE is no exception. There is a degradation in system performance when using any form of encryption because the computer must decrypt everything on-the-fly as it is used. I have found this reduction in processor power to be minimal, though your
circumstances may vary depending on your processor speed, the encryption algorithm you use, and some other factors. Power users who depend on their devices for processor-heavy functions like video editing or graphic design may find this slow-down noticeable but the overwhelming majority of users will not.

FULL-DISK ENCRYPTION ON REMOVABLE STORAGE​

Full-disk encryption can apply to system and non-system drives alike. System drives are the hard drives upon which the computer’s operating system resides and from which it runs; non-system drives are other disks that are connected to
the computer such as auxiliary internal or external hard drives, SD cards, and USB flash drives. If you do not enable full-disk encryption for your system drive we highly recommend enabling it for your non-system drives and devices, especially those with which you travel. USB flash drives are notoriously easy to lose, and the
loss of one containing sensitive data can be extremely damaging.

ENCRYPTION ALGORITHMS:
There are three encryption algorithms that are used with the programs that will be discussed in this chapter. They are AES (Advanced Encryption Standard), Serpent, and Twofish. AES is currently the United States
Government’s only approved algorithm for protection of classified information.

The algorithm that underlies AES was selected by the National Institute of Standards and Technology (NIST), in a contest to transition the US Government to
a new, improved algorithm from the elderly and inferior 3DES. After selection by NIST the AES algorithm was further vetted by the National Security Agency (NSA)
before being certified for the protection of classified information in 2003. Currently there are no known workable defeats for AES.

Serpent and Twofish were both finalists in the AES competition, and both are very strong algorithms. While some of the programs discussed below will allow you to use cascaded algorithms (i.e. AES encrypted by Serpent, which is then encrypted
by Twofish), AES is currently susceptible to no known defeats, as is widely believed to be more than sufficient. While I leave it in the hands of the user to decide which
algorithm he or she trusts, I add a morsel of food for thought. Cryptanalysts are probably much busier working on defeats for AES than they are for Serpent or
Twofish because of the ubiquity and popularity of AES. For this reason, we consider using all of the algorithms for different things.

VERIFYING FILE INTEGRITY​

Verifying the integrity of a computer program before installing and using it is incredibly important, especially for security software. Verifying the program ensures that it has not been modified. While a modified or look-alike version of
more conventional software is almost certainly an attack vector for malware, modified versions of security applications are typically more insidious. A security
application that has been modified will probably have no immediately obvious indicators that it has been tampered with. The program will function normally and appear to do all of the things it was designed to do. The changes made to it will be
visible only to someone closely examining the source code. The purpose for such a modification would be to weaken the security it offers or insert a backdoor. This is
unacceptable if you are truly relying on a security program to keep your data safe.

The simplest way to ensure you are getting the original, unmodified version of the application is to verify its checksum. Every file created in Linux (or any other
operating system) has a checksum.

A checksum is simply the product of all the 1s and 0S of a program when hashed through a cryptographic algorithm. Hashing produces a reliable output code that will be of a consistent length, and will not change, no matter how many times the program is copied, moved, or renamed, as long as its underlying source code remains the same. If even the slightest modification has been made to the code, the checksum will also change drastically. The example below shows the difference
even very subtle changes to the word “hello” can make when this text is hashedbusing the MD5 hashing algorithm. Even though only one letter has been changed
in each example of the word, you will notice that the output product for each is drastically different.