Lab - Linux Secure Storage

This guide aims to study the security mechanisms of the Linux Operating System. In particular the methods for encrypted storage of data at rest

Introduction

Computers are frequently secure against on-line attacks, which target services and file permissions. This is enforced by the operating system kernel through the use of authentication mechanisms and file permissions, and effectively is able to keep an attacker away from accessing confidential data. However, this only provides protection against remote attackers. If a computer, such as a laptop, is stolen, or simply, the attacker has physical access to it, these security measures are insufficient. By booting from an external medium, such as a flash drive, or a CD, and by directly accessing the file system and block devices, all data will be available for inspection, or even tampering.

There are several ways of securing a computer from off-line attacks, which the BIOS password is an example. Without the proper secret, the computer can be restricted to boot, preventing external boot attacks. However, the system is still vulnerable to off-line attacks which target the storage media directly. That is, an hard disk can be removed from a computer, and its content analyzed. Moreover, if using swap memory space, some memory content, potentially containing private data, can be extracted.

Preventing this type of attacks requires the usage of cryptographic mechanisms in order to secure some of the stored data. Although not handled by this laboratory guide, due to the lack of proper hardware, a solution that can be considered is hardware-based encryption of the entire hard disk, handled transparently by the hard disk controller. One example of such product is the Seagate line of Self-Encrypting Drives (SED).

The following sections will describe several methods to achieve security against off-line attacks, when using software solutions, ordered by level of scope.

File System Level

With the lowest scope is the technique which allows storing secure contents, by encrypting the content of sensitive files. With these solutions, the file system structure is available to an attacker, as well as some details of the stored files (permissions, size). However, it will not be easy to access the content, due to the use of an encryption algorithm.

One of the first solutions was the Cryptographic File System (CFS) for Unix, BSD and Linux (circa 1993). Microsoft NTFS also supported encrypted files since the year 2000, as this feature, named Encrypting File System (EFS) was introduced in Windows 2000. Nowadays there are many solutions, being EncFS one of the most well known.

EncFS operates by providing an overlay over an existing directory, which can a remote mount point, so that all files written to that overlay are ciphered in real time. A great advantage is that when using EncFS, one unprivileged user can securely store files in shared, remote locations such as a SAMBA or NFS export. The drawback is that metadata is not ciphered. Therefore, file size, permissions, and file modification time will be publicly available.

The first step in using EncFS is to select two directories, one to store the encrypted files, and another to mount the encrypted file system. In this guide, please use /opt/encfs-store as the directory to store files, and /opt/encfs-mount as the directory to access the files:

mkdir -p /opt/encfs-store
mkdir -p /opt/encfs-mount

The next step is to install encfs and then activate the EncFS, by issuing:

encfs /opt/encfs-store /opt/encfs-mount

During the setup process, choose x for greater insight regarding the methods used. After the process is complete, the new file system is available at /opt/encfs-mount. Create some files and directories in this mount point. Then observe the content of the directory /opt/encfs-store. You can unmount the EncFS by issuing umount /opt/encfs-mount.

Unmount the system, delete all files in /opt/encfs-store and repeat the process. This time, select a different set of options. In particular those related to the name of the files. Mount the file system and observe the result of creating files in the /opt/encfs-store directory.

Virtual Block Device

Increasing the level of security will require that file metadata is not available to others. One method of achieving this is by creating a file, which can be stored in a public location, and use that file as a secure block device. Block devices are devices such as flash drives and hard disks, which export a block-based interface. On top of these devices it is possible to create partitions, and file systems, such as the EXT4 file system. Although the EXT4 file system doesn’t support online encryption, if the underlying block device transparently ciphers information, secure data storage can be achieved.

The purpose of a virtual block device, or loopback device, is to map a standard file as a block device. An interesting advantage of this method is that the software mapping the file can cipher information as it is written to the loopback device.

In order to create a loopback device, first it is required to create a file to be mapped. This file can be considered to be similar to a VDI or QCOW image used by VirtualBox.

Create a 100MB file located at /opt/secure-file:

dd if=/dev/zero of=/opt/secure-file bs=1M count=100

Afterwards, map the file as a block device, and set that all operations should be ciphered/deciphered:

sudo cryptsetup luksFormat /opt/secure-file
sudo cryptsetup luksOpen /opt/secure-file secret-data

After this step, the node /dev/mapper/secret-data can be handled as a block device, and all accesses are directed to the /opt/secure-file. As with all block devices, a file system much be created, and then mounted. In this case, you should also create a directory named /opt/secure-file-mount:

mkdir -p /opt/secure-file-mount
mkfs.ext4 /dev/mapper/secret-data
mount /dev/mapper/secret-data /opt/secure-file-mount

If the process is complete, the file system can be accessed through the /opt/secure-file-mount directory. Copy some text files to this directory. As you can see, the file size is limited, and cannot be modified. This is a limitation of the method used. You can use the strings command over the /opt/secure-file-mount to check that the content is actually ciphered and pseudo-random.

You can unmount the file system by issuing:

umount /opt/secure-file-mount

And you can destroy the mapping attributed to the /dev/mapper/secret-data node by issuing:

sudo cryptsetup luksClose secret-data

After this step, the file is free from any binding and can be transported to another system, keeping all information secure.

Full Disk Encryption

The previous methods allowed to store private data in common folders. In the first case it is even possible to share the same storage between several non-colliding users. The next level of privacy is the use of full disk encryption so that all contents are kept private. While this method provides superior security, it is the less flexible as encryption will be made at the level of an entire block storage device, or an entire partition. Access to data will be restricted until the proper key is provided, and all contents in the hard disk will be encrypted.

  • The first step is to add a second disk to the Virtual Machine. This second disk will be ciphered.

  • Then, the cryptsetup package must be installed with apt.

  • Use gparted and create one partition.

  • Format the partition to the LUKS format so that it can be used as a encrypted partition. In this case /dev/sdb1 will be used, but your device may be a different one: cryptsetup -v --cipher aes-xts-plain --key-size 256 --hash sha1 --iter-time 1000 --use-urandom --verify-passphrase luksFormat /dev/sdb1

  • Create a directory named /mnt/data.

  • Create a mapping to the encrypted partition, then a file system over it, and mount the file system to the /mnt/data directory:

cryptsetup luksOpen  /dev/sdb1 data_crypt
mkfs.ext4 /dev/mapper/data_crypt
tune2fs -L "data_crypt" /dev/mapper/data_crypt
mount /dev/mapper/data_crypt /mnt/data
  • Edit /etc/fstab and add /dev/mapper/data_crypt /mnt/data ext4 rw,noatime 0 1. After this step, the partition will be available at /mnt/data and all information written to it will be ciphered at a block level. Therefore, independently of the file system on top of it.

This process could also be applied to the root partition. However, the process has some complexity and is out of scope for this guide.

To close the device, the file system must be unmounted, and then the partition mapping removed:

umount /mnt/data
cryptsetup luksClose /dev/mapper/data_crypt

References

Acknowledgements

Authored by João Paulo Barraca, André Zúquete, and Hélder Gomes

2022
Previous
Next

Last updated on 1 Sep 2022