Luks encryption. Data encryption systems LUKS, EncFS and CryptoFS for Linux
Home directory encryption provides reliable protection for data stored on your hard drive or other storage media. Encryption is especially important on laptops, on computers with multiple access, as well as in any other conditions. Home directory encryption is offered when installing Linux Mint.
The main catch with full encryption of the home directory is that you need to “move” the directory with the encrypted data beyond the mount point.
Performance decreases slightly, at least until SWAP is used. SWAP is a special disk partition or file into which the operating system moves individual blocks of RAM when there is not enough RAM to run applications. SWAP is also encrypted if you select encryption of the home directory in the installer, and sleep mode stops working.
Not encrypting SWAP when the home directory is encrypted is potentially dangerous, since data from encrypted files may end up there in clear text - the whole point of encryption is lost. Starting with version 14 of Linux Mint, during installation you can choose the option to encrypt the entire disk. This option is most suitable for storing personal data on portable devices (which typically have only one user).
1.3 Encryption in gnome – Seahorse
Linux Mint has a built-in Passwords and Keys utility, or Seahorse. Using its capabilities, the user can operate with all keys, passwords, as well as certificates that are available in this OS.
Essentially, Seahorse is an application for GNOME (GNOME is a free desktop environment for Unix-like operating systems), which is a frontend to GnuPG (a free program for encrypting information and creating electronic digital signatures) and is designed to manage encryption keys and passwords. It replaced GNOME Keyring, which was completely replaced in GNOME 2.22, although it was announced back in GNOME 2.18. Allows you to perform all operations that previously needed to be done on the command line and combining them under a single interface:
manage the security of your work environment and OpenPGP and SSH keys;
encrypt, expand and scan files and text;
add and check digital signatures to documents;
synchronize keys with key servers;
create and publish keys;
reserve key information;
add to images in any supported GDK as an OpenGPG photo ID;
1.4 TrueCrypt
TrueCrypt has a fairly convenient graphical interface, but, unfortunately, the developers have hardcoded integration with the Nautilus file manager into the code.
You can use different methods to encrypt data.
First you need to create a so-called container that will contain file folders intended for encryption. A container can be a file with an arbitrary name or even an entire disk partition. To access the container, you must specify a password, and you can also create a key file (optional) with which the information will be encrypted. Container size is limited.
Creating encrypted partitions/files
Creating a key file:
truecrypt -create-keyfile /home/user/test/file , where file is the name of the key file.
Creating a container, in this case a section:
sudo truecrypt -k /home/user/test/file -c /dev/sda9
Instead of the /dev/sda9 partition, you can also specify a file, for example /home/user/test/cryptofile, but in this case you will need to specify its size, this is done with the -size=5G parameter before the -c parameter. The example above will create a 5GB cryptofile. Sometimes TrueCrypt only accepts the size in bytes; for 5 GB you can either calculate the value in advance and specify -size=5368709120, or write it as follows: -size=`echo 1024^3*5 | bc`.
The already created key file will be used for encryption.
When creating, you will be offered a choice of container type (normal/hidden), file system (FAT, ext2/3/4 or without FS), in this example the mode without using FS was selected. You will also be offered a choice of encryption algorithm (for example, AES), as well as a hash algorithm (for example, SHA-1) for encrypting data streams.
TrueCrypt is used to encrypt data on the fly, that is, you can mount a container and work with the files in it as usual (open/edit/close/create/delete), which is very convenient.
The encrypted partition/file has been created. Now, if you need to format its internal file system (hereinafter referred to as FS), you should do the following.
Select the required section using Truecrypt:
truecrypt -k /home/user/test/file /dev/sda9
By default, the Truecrypt-created device /dev/mapper/truecrypt0 will be used. By accessing this device, you can change, for example, the FS in an encrypted container. In this case, this needs to be done.
sudo mkfs.ext4 -v /dev/mapper/truecrypt0
This is how the ext4 FS was created inside this encrypted container.
Next, since this container is already “attached” to the device /dev/mapper/truecrypt0, all that remains is to simply mount it to some directory. This mount directory must already exist on the system.
sudo mount /dev/mapper/truecrypt0 /mnt/crypto, where /mnt/crypto is the directory to which the encrypted container is mounted.
truecrypt -d
Now, without knowing the key file and password, no one will be able to read the hidden information.
Introduction
Storing data in encrypted form is a great way to protect information so that it does not reach an attacker. Cryptographic systems are being developed to protect intellectual property, trade secrets or personal information. They can come in a variety of forms, offer varying levels of functionality, and contain any number of options to suit a wide range of operating systems and environments. Today, the number of modern cryptographic methods, algorithms and solutions is much greater than before. And the quality of development is much better. Moreover, there are many workable solutions on the market based on open source, which allows you to achieve a good level of protection without spending large sums of money.
In December 2005, the Ponemon Institute conducted a survey among various information security experts regarding encryption and data protection. Among the 6,298 surveyed, only 4 percent of respondents used enterprise-wide encryption. From the same survey, three main reasons emerged for persistent opposition to official encryption rules:
- 69% of respondents mentioned performance problems;
- 44% of respondents mentioned difficulties with implementation;
- 25% of respondents spoke about the high cost of implementing cryptographic algorithms.
In many countries, organizations are exposed to a variety of pressures to increase transparency in their work. But, on the other hand, they bear the statutory responsibility for failure to ensure the safety of confidential information. This was, in particular, the case with shoe stores of the DSW corporation in the USA).
The US Federal Trade Commission filed a lawsuit against DSW, which alleged failure to provide adequate levels of information security and failure to take adequate measures to build adequate systems to restrict access to this data, as well as unsatisfactory security network connections between shops and office computers. In the case of DSW, approximately 1.4 million credit cards and approximately 96,000 checking accounts were potentially accessible to criminals. And before agreements between the company and the FTC were reached, these accounts had already been used illegally.
Nowadays, software and engineering solutions for data encryption are more accessible than ever. A USB key, becoming cheaper day by day, is increasingly used instead of smart cards. The latter, in turn, can also often be found, because most laptops contain a smart card reader.
Consumers are increasingly beginning to think about the dangers related to the theft of personal information, owner data, and credit card numbers. And these fears are only fueled by reports of massive sales of stolen information of this kind from institutions that are entrusted with such valuable data.
Consumers are also beginning to realize that it is important to protect personal information not only online, but also offline. After all, unwanted access to your data doesn't always happen over the network. This question is especially relevant for those whose unprotected laptops may end up either in the hands of service personnel for configuration changes, or in service for repair.
Encryption technical issues
Encryption functions are required in all modern multi-user computer systems where data, processes, and user information are logically separated. To authenticate a user to similar system, logins and passwords are hashed and compared with hashes already available in the system (or the hash is used to decrypt the session key, which is then checked for validity). To prevent unauthorized viewing of personal information, individual files or entire sections may be stored inside encrypted containers. And network protocols, for example, SSL\TLS and IPSec, allow, if necessary, to strengthen cryptographic protection various devices(/dev/random, /dev/urandom, etc.) using modular algorithms that work with the operating system kernel.
The goal of any disk encryption technology is to protect against unwanted access to personal information and to reduce damage from loss of intellectual property due to illegal access or theft of a physical device. operating room Linux system with kernel version 2.6.4 introduced an improved cryptographic infrastructure that simply and reliably protects personal data at many levels software. There are entire standards for storing encrypted data at a low level, like Linux Unified Key Setup (LUKS), and implementations at the user level, for example, the EncFS and CryptoFS file systems, which, in turn, are based on the Fast Userspace File System ( FUSE) for Linux. Of course, any cryptographic system is only as resistant to hacking as its passwords and access keys. There are three main levels at which encryption technologies are used:
- file and file system level (file-by-file encryption, file container);
- low block level (container with file system);
- hardware level (specialized cryptographic devices).
File-level encryption is a very simple method usually used for file sharing. Encryption is used occasionally, which is convenient for sending a reasonable number of files. For multi-user file systems, the problem of key management arises because folders and files of different users are encrypted with different keys. Of course, you can use one key, but then we get a technology reminiscent of disk encryption. As always, it is the user's responsibility to choose the most secure password possible.
More advanced cryptographic applications work at the file system level, tracking files as they are created, written, or modified. This method provides the best protection for personal information no matter how it is used, and it is also good for large numbers of files. In addition, there is no need to worry about applications that cannot encrypt files individually.
Some cryptographic technologies are free and included in many distributions. By the way, latest versions Windows is equipped with a special file system that supports Encrypted File System (EFS). Fedora supports a number of encryption options, including LUKS (you can enable LUKS support on Windows if you use FAT or FAT32 file systems and the FreeOTFE application). And FUSE and EncFS are available in the Extras packages. CryptoFS can also be installed by downloading from official website. .
The FUSE infrastructure consists of a loadable kernel module and a userspace library that serves as the basis for both the CryptoFS and Encrypted file system (EncFS) file systems. By its structure, FUSE does not affect the kernel source code and at the same time provides high flexibility for implementing many interesting additions, for example, the Secure Shell file system (SSHFS).
CryptoFS stores encrypted data in a familiar directory structure, divided into two main parts: text information (list of files, folders, archives) and the encrypted data itself. You can only remount an encrypted directory using the key. When using CryptoFS, you do not need special privileges, and setup is also easy.
The EncFS file system is also a userspace implementation based on the FUSE library, which provides protection against information theft and works on the principle of file-by-file encryption. It inherited its structure from earlier versions, but with improvements in both form and function. The EncFS file system can be dynamically expanded to meet increasing user requirements. Files can be encrypted according to various parameters (for example, when content changes, by attributes, etc.). Essentially, the underlying storage for EncFS can be anything from an ISO image to a network partition or even a distributed file system.
Both file systems operate on an end-to-end basis and can be used on top of other file systems and logical abstractions, such as a journaled or extended file system, which can be distributed across multiple physical media via a logical partition manager (LVM). The following illustration schematically shows how this file system works: In this diagram, the visible directory is labeled /mount (EncFS plaintext data layer).
Userspace overlay showing the interaction between FUSE and EncFS.
Beneath the file system abstraction layer are low-level (block) encryption schemes similar to those used in LUKS. Schemes of this type work only on disk blocks, without paying attention to higher-level file system abstractions. Similar schemes can be used for page files, for various containers, or even for entire physical media, including full encryption of the root partition.
LUKS works without exact knowledge of the file system format.
LUKS is designed in accordance with Trusted Key Setup #1 (TKS1) and is compatible with Windows using any common file system format (FAT/FAT32). The system is well suited for mobile users, supports Gnu Privacy Guard (GPG) key issuance and revocation, and is completely free. LUKS is capable of much more than any other implementation described in this article. Moreover, LUKS supports a large number of solutions for creating and managing LUKS encrypted devices.
The CryptoFS file system only accepts a password, while media encrypted with LUKS works with any PGP (Pretty Good Privacy) keys with any number of passwords. EncFS also uses a password to protect files, but it opens the key stored in the corresponding root directory.
The differences between low-level and userspace implementations are best seen in practical tests. At a low level, data can be transferred transparently to the file system, which manages read and write operations much more efficiently.
Test configuration
Our test platform was the Dell Latitude C610 laptop, a little outdated, but still a fairly fast representative of 2002-style technology. When powered by battery, the C610 reduces the processor frequency to 733 MHz. Therefore, during testing we did not unplug the laptop from the outlet. The following table shows the laptop configuration
Test results were obtained using the EXT3 file system under Linux. Perhaps EXT3 is not the most productive compared to other journaled file systems. But experiments with fine-tuning the system format, block size, drive parameters, etc. are not the objectives of our testing, since they do not meet the criteria for simple setup and configuration. Let us recall that the purpose of the article was to show how cryptographic solutions for Linux allow you to simply, efficiently and cheaply create secure data storage.
Installation
LUKS, FUSE and EncFS are available in the Fedora distribution, so no additional effort is required. But CryptoFS will have to be downloaded separately.
Compiling CryptoFS from source code is quite simple. Unpack the archive, run the configuration script in the destination directory, then run make as shown in the illustration. The configuration file contains four parameters: encryption cipher, message digest algorithm, block size and encryption salt count.
The installation process for CryptoFS is simple.
The setup consists of specifying the paths of the starting and ending directories (for encrypted and unencrypted data). You can then run the cryptofs command as shown in the following figure.
Setting up CryptoFS.
You can then run the mount command, after which you will be able to see the mounted partition.
First make sure the FUSE kernel module (modprobe fuse) is loaded. EncFS simplifies the process of creating an encrypted container, as seen in the following illustration.
If you skip the key installation process (which is specific to each situation), LUKS can be easily configured as shown below.
Tests and performance analysis
The performance differences between a native installation and an installation in a LUKS encrypted environment are fairly minor. Especially considering the noticeable difference between userspace solutions. To evaluate the performance of encrypted file systems one by one, we used Iozone. For tests, records from 4 KB to 16 MB are used, the file size varies from 64 KB to 512 MB, and the result is indicated in KB/s.
Conclusion
At least where LUKS is used, you don’t have to worry about performance. Although, of course, some performance loss is caused by "transparent" data encryption. The LUKS system is easy and simple to install, and can be used on both Linux and Windows.
Corporate users will likely have to face restrictions related to company policies. They often ban open source solutions or ban certain implementations. In addition, sometimes there are restrictions on the import/export of encryption technologies regarding the strength of the code, or the IT department requires telephone support from the solution provider, which makes LUKS, EncFS and CryptoFS unnecessary. In any case, LUKS is a great solution if such problems do not bother you. A good option for small businesses or home users.
But you should remember that data encryption is not a panacea. Since encryption is performed transparently, any Trojan program running on behalf of the user can access the encrypted data.
Editor's opinion
CryptoFS and EncFS are userspace implementations. As we explained earlier, they are simple in design and implementation, but come at the cost of performance and capabilities. This is especially obvious when compared with LUKS. Not only is it noticeably faster, but it also supports one or more PGP keys and can be used across an entire partition.
Userspace containers are important primarily for users who want to protect personal information in a multi-user environment. And who needs to protect their data so that even the administrator cannot access hardware or software resources. In addition to the performance benefits and cross-platform support, LUKS integrates well with GNOME and PGP key management systems. And the lightness everyday use The encrypted LUKS partitions are simply impressive. By the way, EncFS supports Pluggable Authentication Module (PAM) under Linux in appropriate environments.
It’s no secret that today, data encryption is perhaps the only way to somehow save it. Today we will learn how to create an encrypted partition in Linux using the luks (Linux Unified Key Setup) standard. I will provide screenshots from the CentOS Linux operating system as an example.
So, first of all, let's prepare the section that we will encrypt. Within its virtual machine I created new disk, connected it to the SATA interface, the /dev/sdb device appeared in the system
Let's create a main section on it:
# fdisk /dev/sdb
We created 1 partition (sdb1), allocated all the free space to it.
Great, now let's format the /dev/sdb1 partition using cryptographic protection using a passphrase. We will be asked to enter a password. Let's repeat it twice so as not to make a mistake.
# cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb1
The default algorithm is AES 256bit. If necessary, you can select a different algorithm by specifying the keys -c algorithm -s key length
# cryptsetup -c aes -s 1024 --verbose --verify-passphrase luksFormat /dev/sdb1
Then we activate the crypto container under the name safe:
# cryptsetup luksOpen /dev/sdb1 safe
As a result, we create a new block device in the /dev/mapper/ directory with the name safe.
We create file system:
# mkfs.ext3 /dev/mapper/safe
What if we want our partition to be activated every time the system starts (of course, asking for a passphrase)?
Let's edit the /etc/crypttab file, which is similar to /etc/fstab
# vim /etc/crypttab
Let's add the line there:
safe /dev/sdb1 none
And in the /etc/fstab file the following:
/dev/mapper/safe /safe ext3 defaults 0 0
Yes, the situation. We have created a crypto section. We know the key. Is it possible to make the section accessible not only by our key, but also by another one? That is, we want to give access to “Vasya” so that he can work on an equal basis with us. Easily.
Let's add another key to the crypto container.
In total, you can create up to 8 keys, each of which fits in its own slot.
You can show occupied slots like this:
# cryptsetup luksDump /dev/sdb1
As you can see, slots 0 and 1 are occupied. Key files can also be used instead of passwords.
You can show the status of the crypto container like this:
# cryptsetup status safe
Practical example.
Goal: Protect USB device from annoying eyes.
Let's connect the flash drive to our system:
The flash drive was identified as an sdc device. This means that the /dev/sdc device has appeared. If the flash drive had fat or ntfs partitions, then it’s better to throw the information somewhere, because after encrypting the device everything will be lost.
So, we can partition the flash drive using fdisk, we can leave it as is.
# cryptsetup luksFormat /dev/sdc
Enter the passphrase.
Now let's connect our encrypted device to mark it for the new file system:
# cryptsetup luksOpen /dev/sdc flash
Now we will be asked for a passphrase, after entering which a new device /dev/mapper/ will appear in the system<имя>, in our case flash.
Let's create a file system on this device:
# mkfs.ext3 /dev/mapper/flash
Ready. Well, it’s time to create keys that will be used to access the device. You can prepare several keys (up to 8 slots in total, although the 0th slot is already occupied by a passphrase, but it can be deleted).
# dd if=/dev/urandom of=~/keyfile.key bs=1 count=256
Thus, we will create a 256 byte file filled with random numbers. You can check this like this:
# xxd ~/keyfile.key
Really. completely random. Now all that remains is to add this key to our flash drive.
Let's disable the crypto container for now.
# cryptsetup luksClose flash
Add a key:
# cryptsetup luksAddKey /dev/sdc ~/keyfile.key
We will be prompted to enter a passphrase to ensure that we have access to this storage.
# cryptsetup luksDump /dev/sdc
Great! Now let's save the key in a safe place. We will need it to access the container.
Example 1.
User “A” wants to upload a file to a flash drive, knowing the passphrase:
We unlocked it using a password, creating a mydisk device, then mounted mydisk in the home directory. Created text file hello.txt with content. The container has been disabled.
Example 2.
We unlocked it using the key file and created a flashka device. We mounted it in the home directory of the user sergey, read the file - everything was ok!
