Disk (a la TrueCrypt). I know there has been work to add encryption support to GRUB2, but it's not ready yet. Any other options?

(Note that I actually mean full disk encryption here, including /boot)

Most of the answers describe a setup where /boot is not encrypted, and some of them try to explain why an unencrypted /boot should be ok.

Without getting into a debate about why I actually need /boot to be encrypted, here's an article that describes exactly what I need, based on a modified version of GRUB2:

• http://xercestech.com/full-system-encryption-for-linux.geek

The problem is that these modifications don't seem to be supported in the current GRUB2 codebase (or maybe I'm missing something).

8 Solutions collect form web for “Linux boot loaders that support full disk encryption?”

I think that Current version GRUB2 does not support loading and decrypting LUKS partitions on its own (it contains some ciphers, but I think they are only used for password support). I can't check the experimental development branch, but there are some hints on the GRUB page that some work is planned to implement what you want to do.

Update (2015) : latest version GRUB2 (2.00) already contains code to access the encrypted LUKS and GELI partitions. (The xercestch.com link that the OP provided mentions the first fixes for this, but they are now included in the latest version).

However, if you are trying to encrypt the entire drive for security reasons, note that an unencrypted bootloader (such as TrueCrypt, BitLocker, or a modified GRUB) does not provide any more protection than an unencrypted /boot partition (as pointed out by SP in the comment above). Anyone with physical access to the computer can just as easily replace it with the custom version. It's even mentioned in the xercestech.com article you linked:

To be clear, this in no way makes your system any less vulnerable to an offline attack; if an attacker were to replace your bootloader with their own or redirect the boot process to load their own code, your system could still be compromised.

Please note that everything software products for full disk encryption have this weakness, regardless of whether they use an unencrypted bootloader or an unencrypted boot/preboot partition. Even products that support TPM (Trusted Platform Module) chips, such as BitLocker, can be implemented without changing the hardware.

A better approach would be:

1. decrypt at the BIOS level (in motherboard either on a disk adapter or external hardware [smart card], with or without a TPM chip), or
2. carry the PBA (preboot authorization) authorization code (/boot partition in this case) on a removable device (such as a smart card or USB drive).

To do this the second way, you can check out the Linux Full Disk Encryption (LFDE) project at: http://lfde.org/, which provides a post-installation script to move the /boot partition to external USB drive by encrypting the key with GPG and storing it on USB too. This way, the weak part of the boot path (the unencrypted /boot partition) is always with you (you will be the only one with physical access to the decryption code and key). ( Note: This site has been lost and the author's blog has also disappeared, however you can find the old files at https://github.com/mv-code/lfde, just noting that the last development was done 6 years ago). As an easier alternative, you can install an unencrypted boot partition on a USB drive when installing the OS.

Best regards, M.V.

Make your first RAMdisk and /boot folder unencrypted.

This will bring up a "minimal" kernel with drivers and support to switch to the "real" root file system, which is encrypted.

Before you declare "it's a hack", remember - most (if not all) Linux distributions loaded by default today. This explicitly allows your system to boot and load the root FS using modules that need to be loaded from the filesystem. (Kind of a chicken and egg problem). For example, if your root filesystem was on a hardware RAID volume and you needed to load its driver before you could mount the root FS.

I looked at the link you posted - although there is no boot partition, there is still an unencrypted bootloader on the hard drive that can be accessed and compromised by a malicious attack. I've been looking for a similar setup where there is no unencrypted data on the hard drive, but so far I've only come up with running the bootloader from a removable drive.

I believe that most of them, what you need is instructions on how to install an OS with encrypted HD first.

Ubuntu has good page with instructions for creating encrypted partitions, LMVP, folders, etc., just your version of your distribution...

No, I think not.

Do you really need to encrypt/download? I suspect not. The rest of the file system can be encrypted with regular software Linux provisioning which is in initramfs in /boot and prompts the user accordingly.

You seem to be asking for something that can't be done and comparing it to Windows solution, which hides the implementation from you, but actually does the same thing that Linux does.

The closest solution I can think of is to use HDD, which implements password security and encryption. Some Thinkpad laptops use these hardware solutions.

The answer is outlined in the article. "This is now possible with extensions to the next generation GRUB2 bootloader, which has been patched to support not only" and "we want to install a new image with luks grub2 support later" and "We will now compile the GRUB2 source with LUKS support. "It seems there is a fix or extension that you need to obtain and enable with GRUB2 or a forked GRUB2 source.

Grub2 version 2.02~beta3 can do a lot that Grub2 version 2.02~beta2 cannot do, tested by me:

1. Booting using a Super Grub 2 disk
2. Type "c" to go to the command line
3. Enter the commands to mount the encrypted partition I want
   • insmod lux
   • cryptomount(hd0, #) // where # represents the encrypted partition
4. Enter key phrase and enter some commands
   • multiboot (crypto0) /grub/i386-pc/core.img
   • boot

This will load another Grub2 that is inside the encrypted partition, evil crazy attack has no place here... I boot from a CD (read only) and then mount the encrypted partition (not the passphrase, anything!), then booting from inside an encrypted partition and booting Grub2 with its own menu, etc.

Warning: Grub2 version 2.02~beta2 cannot do the same because it has some bugs (which seem to be fixed in Grub2 version 2.02~beta3) related to the cryptomount command...

beta2 errors I'm talking about are:

1. It doesn't actually mount the encrypted partition, so it doesn't allow you to access (crypto0)/*
2. If there is more than one encrypted partition, using cryptomount -a only requires one passphrase
3. After running cryptomount once it runs again, does nothing

on beta 3:

1. It does mount the encrypted partition and allows you to access files via (crypto0)/* or (crypto1)/* etc if more than one is mounted at the same time
2. It asks for each passphrase (one per encrypted section)
3. This allows you to run it as many times as you need, you can install one, then another, etc.

Side note: I haven't figured out how to unmount them other than rebooting or downloading another or one boot loader grub2/other etc.

Hope this helps clear things up, and hopefully the Grub2 2.02~beta3 version will be integrated into the LiveCD so we can install it without having to compile it ourselves.

PD: With a Super Grub 2 disk, I don't see a way to install Grub2 version 2.02~beta3 on the MBR/boot partition, etc.

: - Russian

Active development of the page is completed

If you have something to add, then supplement the sections with new information. Our typos and errors in the article can be easily edited, there is no need to report this by email, please respect the style of this page and use section dividers (gray lines of varying thicknesses).

Data encryption in Debian

Many people think that there is no need to encrypt their data. However, in everyday life we ​​often encounter situations such as “a flash drive is lost” or “the laptop is being repaired”, etc. If your data is encrypted, then you don’t have to worry about it at all: no one will publish it on the Internet or use it in any other way.

Encryption using cryptsetup

Let's install the necessary components:

# apt-get install cryptsetup

Standard syntax

/dev/sda2. Let's enter the command:

# cryptsetup create sda2_crypt /dev/sda2

This command will create an encrypted connection to our disk. In the catalog /dev/mapper A new device will appear with the name we requested: /dev/mapper/sda2_crypt, accessing which we use encrypted disk access. In the case of LUKS, the name will be /dev/mapper/sda2_crypt

If there was already a file system on the disk and we would like to save the data on it, then we need to encrypt it for subsequent use:

# dd if=/dev/sda2 of=/dev/mapper/sda2_crypt

If it is created new disk on an empty partition, you can format it:

# mkfs.ext3 /dev/mapper/sda2_crypt

Later you can mount this disk anywhere:

# mount /dev/mapper/sda2_crypt /path/to/mount/point

Check data integrity (as usual, it is better to use only in an unmounted state):

# fsck.ext3 /dev/mapper/sda2_crypt

And even decrypt back if we no longer want to use encryption:

# dd if=/dev/mapper/sda2_crypt of=/dev/sda2

LUKS syntax

The above steps can be done according to the LUKS standard

Initialize the section:

cryptsetup luksFormat /dev/sda2

We connect to the system:

cryptsetup luksOpen /dev/sda2 sda2_crypt

Format:

mkfs.ext4 -v -L DATA /dev/mapper/sda2_crypt

We mount:

mount /dev/mapper/sda2_crypt /mnt/data

The partition can be manually disabled on the system

cryptsetup luksClose sda2_crypt

Connection at startup

The file used for this purpose is crypttab.

For our disk, we will write the following line into it:

nano /etc/crypttab # name mapper device key parameters/options # With standard syntax sda2_crypt /dev/sda2 none aes-cbc-plain:sha256 # and\or under the LUKS standard sda2_crypt /dev/sda2 none luks

By default, encryption is used using the password entered by the user. Thus, every time you boot your computer, the system will ask you each time for a password to connect each encrypted partition. Even if these sections are not registered in fstab.

If we want to mount manually, then we add the option noauto in the "parameters/options" field.

Connecting an encrypted partition manually using data from /etc/crypttab

cryptdisks_start msda2_crypt

And disconnecting from a pre-mounted fs.

cryptdisks_stop sda2_crypt

To automatically mount the fs on the connected encrypted partition, add a line to /etc/fstab

/dev/mapper/sda2_crypt /mnt/data ext4 defaults 0 0

Working with keys in LUKS

The LUKS partition supports 8 different keys, each of which fits in its own slot.

We look at the list of used keys

cryptsetup luksDump /dev/sda2

LUKS can use 2 types of keys – passphrases and files.

You can add a keyword

cryptsetup luksAddKey /dev/sda2

You can add a key file (2048 bit) and set access rights to it.

dd if=/dev/urandom of=/root/ext2.key bs=512 count=4 cryptsetup luksAddKey /dev/sda2 /root/ext2.key chmod 400 /root/sda2.key cryptsetup -d /root/sda2.key luksOpen /dev/sda2 sda2_crypt

To connect when starting using a key, edit /etc/crypttab

nano /etc/crypttab sda2_crypt /dev/sda2 /root/sda2.key luks

You can remove a passphrase or key from a section

cryptsetup luksKillSlot /dev/sda2 1

Emergency mounting in a “foreign” distribution

No one is immune from problems, and sometimes you need to gain access to an encrypted partition from an emergency one. LiveCD disk.

We boot, connect the partition to the system and mount the fs:

cryptsetup luksOpen /dev/sda2 sda2_crypt mount -t ext4 /dev/mapper/sda2_crypt /mnt/backup

After work, unmount the fs and disconnect the encrypted partition from the system

umount /mnt/backup cryptsetup luksClose sda2_crypt

Error messages when shutting down

If the root partition is encrypted, a message will be displayed when shutting down

stopping early crypto disks... failed

This is a technical error. When shutting down, the file systems are always unmounted first and only then the partition is disconnected. As a result, it turns out that the cryptsetup utility located on the root unmounted partition is no longer available to run, which is what INIT tells us. This problem cannot be solved without crutches, because... To do this, you need to consider options for transferring cryptsetup to a RAM disk

A similar situation occurs when using software RAID containing a root partition. 8)

Encryption using the loop-aes module

Encrypting a hard drive partition or flash drive using a password

In this howto encryption method described AES256, other methods can be used similarly (replacing the method name with the appropriate one). We will need the following packages:

# apt-get install loop-aes-utils loop-aes-modules-`uname -r`

Note: if you are using a kernel for which the repository does not have the required loop-aes-modules, you can install the modules with the following commands:

# apt-get install module-assistant loop-aes-source # module-assistant a-i loop-aes

First stage

At the initial stage, we prepare the disk to work with it using encryption.

Let's select the partition of the disk (or flash drive) that we want to encrypt, for example it will be /dev/sda2. Let's enter the command:

# losetup -e AES256 -T /dev/loop0 /dev/sda2

After executing this command, all calls to the device /dev/loop0 will be encrypted and encryptedly redirected to the device /dev/sda2. Now we have both encrypted and unencrypted channels to the data storage device. The data is encrypted using the password you specified when performing losetup.

Now we can, for example, format the device:

# mkfs.ext3 /dev/loop0

We can mount it:

# mount /dev/loop0 /path/to/mount

We can disable encryption:

# losetup -d /dev/loop0

and most importantly, we can encrypt the partition no data loss:

# dd if=/dev/sda2 of=/dev/loop0

and also decrypt if we decide that encryption is not our method:

# dd if=/dev/loop0 of=/dev/sda2

Well, the best part is that we can check the file system for integrity:

# fsck.ext3 /dev/loop0

This feature is not available in all partition encryption methods.

Daily use

If you already had an entry about the section /dev/sda2 in your /etc/fstab, then you just need to add the options, and if not, then write something like the following:

/dev/sda2 /path/to/mount ext3 loop,encryption=AES256 0 0

Now, when loading the operating system, you will be asked for a password to mount.

If you do not want the download process to be interrupted by a password request, you can add options noauto,user on record /etc/fstab:

/dev/sda2 /path/to/mount ext3 loop,encryption=AES256,noauto,user 0 0

Of course, you can mount it manually (or from a script):

# mount /dev/sda2 /path/to/mount -o loop,encryption=AES256

Mounting multiple file systems

Sometimes you want to encrypt several sections with data at the same time, but so as not to enter a sea of ​​passwords for each mount. For example, you have a flash drive that you carry from home to work, a portable hard drive, etc. Or just several partitions/hard drives.

Let's say we have an encrypted partition /dev/sda2, which we mount into the directory every time we boot /mnt1. A new hard drive has appeared /dev/sdb1 and we want it to be automatically mounted into the directory mnt2 when mounting the first one. You can of course create a general system based on something like LVM, however, you can take a simpler route:

register in fstab something like the following line:

/dev/sda2 /mnt1 ext3 noatime,exec,loop,encryption=AES256 0 0 /dev/sdb1 /mnt2 ext3 noatime,exec,loop,encryption=AES256,cleartextkey=/mnt1/key.txt 0 0

When loading, the system mounts the points in the same order as described in fstab, thus, if the first partition is not mounted, the key to mount the second partition will remain unavailable and the second partition will also not be mounted.

The password is stored as plain/text this is certainly not very beautiful, but it is stored on an encrypted partition (which can also be unmounted). You can use it instead gpg-key, but this will not add much security (if they can steal the key, then it won’t make much difference what kind of key it is), encryption option with gpg- the key is described in man losetup, here I will just give an example of an entry in fstab:

/dev/sda2 /mnt1 ext3 noatime,exec,loop,encryption=AES256 0 0 /dev/sdb1 /mnt2 ext3 noatime,exec,loop,encryption=AES256,gpgkey=/mnt1/key.gpg 0 0

Notes

For more information about supported encryption algorithms, see man losetup, there you can also see a description of other program options losetup.

If you have problems installing AES modules, read the documentation that comes with the package loop-aes-source.

GRUB and the encrypted root disk

When installing the root partition on an encrypted disk, GRUB may show crappy messages in the main menu. This is due to unavailability standard font/usr/share/grub/unicode.pf2. Copying the font

cp /usr/share/grub/unicode.pf2 /boot/grub/

Specify the setting

nano /etc/default/grub GRUB_FONT=/boot/grub/unicode.pf2

Apply the setting:

update-grub

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 partition on a disk or a file in which 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 your security working 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.

Do you want to hide your data from prying eyes? We will teach you hard drive encryption techniques.

Over the past year, the topic of Internet data security has come up frequently: first in connection with the Snowden revelations, then with the OpenSSL vulnerability (Heartbleed bug). Shortly before the last one, a less noticeable bug in GnuTLS was discovered. As a result, we began to pay more attention to the security of deleted data; but what about those that are stored on our disk?

Block device stack

Before looking at encryption, it is important to understand how block devices work. They are system interfaces for storage devices such as /dev/sda! Inside a block device is a hardware driver, such as SATA, and the hardware itself. The operating system then interacts with the block device to create a file system on it.

Block devices are usually considered in this capacity, although they have other functions. In particular, such a device can be an interface for a number of other block devices - they can form a stack. And you've already done this: you have a file system on /dev/sda1 (disk partition), and this block device points to /dev/sda (the entire disk).

Technologies such as RAID and LVM (Logical Volume Management) are also block device stacks. You can have LVM on top of a RAID array, which in turn is also located on the block devices of individual disks or their partitions.

Whole-device encryption with dm-crypt works like this: a block device is created on the basis of your storage medium, which encrypts data when stored and decrypts when read. You then mount a standard file system on top of the encrypted device, and it functions just like a regular disk partition.

Many distributions can be installed onto an encrypted disk, but we will look directly at the creation and operation of dm-crypt devices, without touching on the black magic that the installer performs. Dm-crypt uses the kernel device mapping subsystem to control block devices with kernel cryptographic functions for encryption purposes.

Everything is done by the kernel, but at the user level we need software to create and manage dm-crypt devices; This standard tool is cryptsetup. It's probably already installed on your distribution; and if not, then it will certainly be in the main repositories.

Encryption

The default values ​​are usually more than enough, and all available options can be viewed with cryptsetup -help These options are only needed with LuksFormat. When creating a secure device, cryptsetup automatically uses correct settings to open it.

It's best to stick with popular ciphers and hashes unless you have a better reason to choose something else. Methods used less frequently may have hidden flaws simply because they are less tested, which is what happened recently with the Whirlpool hash implementation in the libcgrypt library used by cryptsetup. When making corrections, those systems that were already using defective hashes were affected.

Another reason to stick with conventional methods is portability. This is not important for the internal drive, but if you want to use the encrypted drive on another system, the same hashes and ciphers must be installed there too.

LUKS

LUKS— Linux Unified Key Setup was created to provide a standard, cross-platform (despite the name) format for storing encrypted data on disks. It concerns not encryption methods, but the way information about them is stored.

He is also more in a reliable way storing keys or passwords, since the dm-crypt method is susceptible to hacking. Since LUKS is cross-platform, encrypted devices can also be accessed from Windows using .