Alternatives to File Encryption.
Before we dive deeper into file encryption, let’s consider the alternatives and see if the file encryption is suitable for your needs. Sensitive data can be encrypted on different levels of granularity: full disk encryption, filesystem-level, database level and application level. This article does a good job comparing these approaches. Let’s summarize them.
Full disk encryption (FDE) makes sense for devices that are susceptible to physical loss or theft, such as laptops. But FDE is not going to protect your data from much else including remote hacking attempts and is not suitable for encrypting individual files.
In the case of filesystem-level encryption, the file system performs the encryption directly. This can be accomplished by stacking a cryptographic file system on top of the main one or it might be built in. According to this wiki, some of the advantages are: each file can be encrypted with a separate key (managed by the system) and additional access control through public-key cryptography. Of course, this requires modifying OS configuration and might not be suitable for all users. However, it offers protection suitable for most situations, and it is relatively easy to use. It will be covered in down below.
The database level encryption can target specific parts of data such as a specific column in a table. However, this is a specialized tool that deals with file contents rather than entire files and is thus outside the scope of this article.
Application level encryption, may be optimal when security policies require safeguarding specific data. An application can use encryption to protect data in many ways, and encrypting a file is certainly one of them. We will be discussing an application for encrypting files below.
Encrypting a file with an Application
There are several tools available for encrypting files under Linux. This article lists the most common alternatives. As of today the GnuPG seems to be the most straightforward choice. Why? Because, chances are, it is already installed on your system (unlike ccrypt), the command line is simple (unlike using openssl directly), it is being very actively developed and is configured to use an up to date cypher (AES256 as of today).
If you don’t have gpg installed, you can install it by using a package manager appropriate for your platform such as apt-get:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Encrypt a file with GnuPG:
Top Secret Stuff!
pi@raspberrypi:~ $ gpg -c secret.txt
pi@raspberrypi:~ $ file secret.txt.gpg
secret.txt.gpg: GPG symmetrically encrypted data (AES256 cipher)
pi@raspberrypi:~ $ rm secret.txt
Now, to decrypt:
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
pi@raspberrypi:~ $ cat secret.txt
Top Secret Stuff!
Please note “AES256” above. This is the cypher used for encrypting the file in the example above. It is a 256 bit block sized (secure for now) variant of “Advanced Encryption Standard” (also known as Rijndae) cypher suit. Check out this Wikipedia article for more information.
Setting up Filesystem-level Encryption
According to this fscrypt wiki page, ext4 filesystem has built in support for file encryption. It utilizes fscrypt API to communicate with the OS kernel (assuming encryption feature is enabled). It applies the encryption at directory level. The system can be configured to use different keys for different directories. When a directory is encrypted so is all filename related data (and metadata) such as file names, their contents and subdirectories. Non-filename metadata, such as timestamps, are exempt from encryption. Note: this functionality became available in Linux 4.1 release.
While this README has instructions, here is a brief overview. The system adheres to the concepts of “protectors” and “policies”. “Policy” is an actual key that is used (by OS kernel) for encrypting a directory. “Protector” is a user passphrase or equivalent that is used to protect policies. This two level system allows controlling user’s access to directories without having to re-encrypt every time there is a change in the user accounts.
A common use case would be setting up fscrypt policy to encrypt user home directory with their login passphrases (obtained via PAM) as a protector. Doing so would add an additional level of security and allow safeguarding the user data even if the would be attacker managed to get admin access to the system. Here is an example illustrating what setting it up would look like:
Should we create a new protector? [y/N] y
The following protector sources are available:
1 - Your login passphrase (pam_passphrase)
2 - A custom passphrase (custom_passphrase)
3 - A raw 256-bit key (raw_key)
Enter the source number for the new protector [2 - custom_passphrase]: 1
Enter login passphrase for pi:
"/home/pi/secret_stuff" is now encrypted, unlocked, and ready for use.
This could be completely transparent to the user once set up. The user could add an additional level of security to some subdirectories by specifying different protectors for them.
Conclusion
Encryption is a deep and complex subject and there is much more to cover and it is also a rapidly growing field, especially with the advent of quantum computing. It is crucial to keep in touch with new technological developments as what is secure today could be cracked in a few years. Be assiduous and pay attention to the news.
Works Cited
- Selecting the Right Encryption Approach Thales eSecurity Newsletter, 1 Feb 2019
- Filesystem-level encryption Wikipedia, 10 Jul 2019
- 7 Tools to Encrypt/Decrypt and Password Protect Files in Linux TecMint, 6 Apr 2015
- Fscrypt Arch Linux Wiki, 27 Nov 2019
- Advanced Encryption Standard Wikipedia, 8 Dec 2019
from Linux Hint https://ift.tt/2PSiHpi
0 Comments