Difference between revisions of "Dm-crypt"

From ArchWiki
Jump to: navigation, search
(Partially undo revision 284401 by Kynikos (talk))
(Specialties)
Line 66: Line 66:
  
 
See [[Dm-crypt with LUKS/Specialties]].
 
See [[Dm-crypt with LUKS/Specialties]].
 +
 +
==Securing the unencrypted boot partition==
 +
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR. The script cannot prevent certain type of attacks, but a lot are made harder. No configuration of the script itself is stored in unencrypted {{ic|/boot}}. With a locked/powered-off crypted system this makes it infeasible for an attacker to recognize that an automatic checksum comparison of the partition is done upon boot.
 +
 +
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2). There is also an AUR package: {{AUR|chkboot}} and a slightly updated AUR package {{AUR|chkboot-git}} which includes systemd support.
 +
 +
After installation:
 +
* For classical sysvinit: add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}
 +
* For systemd: add a service file and enable the service: [[systemd]]. The service file might look like:
 +
[Unit]
 +
Description=Check that boot is what we want
 +
Requires=basic.target
 +
After=basic.target
 +
 +
[Service]
 +
Type=oneshot
 +
ExecStart=/usr/local/bin/chkboot.sh
 +
 +
[Install]
 +
WantedBy=multi-user.target
 +
 +
There is a small caveat for systemd: At the time of writing the original {{ic|chkboot.sh}} script provided contains an empty space at the beginning of {{ic|<u> </u>#!/bin/bash}} which has to be removed for the service to start successfully.
 +
 +
As {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostart (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart; Gnome3: gnome-session-properties).
 +
 +
With Arch Linux changes to {{ic|/boot}} are pretty frequent, for example by new kernels rolling-in. Therefore it may be helpful to use the scripts with every full system update. One way to do so:
 +
 +
#!/bin/bash
 +
#
 +
# Note: Insert your <user>  and execute it with sudo for pacman & chkboot to work automagically
 +
#
 +
echo "Pacman update [1] Quickcheck before updating" &
 +
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user>
 +
/usr/local/bin/chkboot.sh
 +
sync # sync disks with any results
 +
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user>
 +
echo "Pacman update [2] Syncing repos for pacman"
 +
pacman -Syu
 +
/usr/local/bin/chkboot.sh
 +
sync
 +
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user>
 +
echo "Pacman update [3] All done, let's roll on ..."
 +
 +
Alternatively to above scripts, a hash check can be set up with [[AIDE]] which can be customized via a very flexible configuration file.
 +
 +
While one of these methods should serve the purpose for most users, they do not address all security problems associated with the unencrypted {{ic|/boot}}. One approach which endeavours to provide a fully authenticated boot chain was published with POTTS as an academic thesis to implement the [http://www1.informatik.uni-erlangen.de/stark STARK] authentication framework.
 +
 +
The POTTS proof-of-concept uses Arch Linux as a base distribution and implements a system boot chain with 
 +
* POTTS - a bootmenu for a one-time authentication message prompt
 +
* TrustedGrub - a grub-legacy implementation which authenticates the kernel and initramfs against TPM chip registers
 +
* TRESOR - a kernel patch which implements AES but keeps the master-key not in RAM but in CPU registers during runtime.   
 +
As part of the thesis [http://13.tc/p/potts/manual.html installation] instructions based on Arch Linux (iso 2013-01) have been published. If you want to try it, be aware these tools are not in standard repositories and the solution will be time consuming to maintain.
  
 
== See also ==
 
== See also ==
 
* [http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions cryptsetup FAQ] - The main and foremost help resource, directly from the developers.
 
* [http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions cryptsetup FAQ] - The main and foremost help resource, directly from the developers.
 
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.
 
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.

Revision as of 02:15, 27 November 2013

Tango-document-new.pngThis article is a stub.Tango-document-new.png

Notes: This article is currently under heavy restructuring: for its latest stable revision see Dm-crypt with LUKS (Discuss in Talk:Dm-crypt#)

Merge-arrows-2.pngThis article or section is a candidate for merging with Plain dm-crypt without LUKS.Merge-arrows-2.png

Notes: Merge in dm-crypt with LUKS/Encrypting an entire system, but then this page will have to be moved to dm-crypt (and all the subpages will have to follow); the introduction will have to be rewritten too. (Discuss in Talk:Plain dm-crypt without LUKS#Merge)

This article focuses on how to set up full system encryption on Arch Linux, using dm-crypt with LUKS.

dm-crypt is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.

LUKS is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.

For more details on how dm-crypt+LUKS compares to other disk encryption solution, see Disk Encryption#Comparison table.

Overview

Warning: Encrypting a disk or partition will erase everything currently on that disk or partition, make appropriate data backups prior to starting.

Also be aware that encrypting a system might not only make the life of laptop thieves more miserable, but also yours if you don't plan ahead on:

  • how to make secure backups of the encrypted system/-setup/data and
  • how to access the encrypted system manually for maintenance.
Keeping those points in mind while deciding on how to use encryption may help to decide on method and tools as well.

The installation of a LUKS-encrypted system is largely the same as installing an unencrypted system. Routine creation of an encrypted system follows these general steps:

Note that the Arch installation media comes with all the tools required for system encryption.

Common scenarios

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: This section is an alternative to #Examples, see Talk:Dm-crypt_with_LUKS/draft#New_idea. Add some introductory text with links to the most important subsections of Dm-crypt with LUKS/Encrypting a non-root file system and Dm-crypt with LUKS/Encrypting an entire system. (Discuss in Talk:Dm-crypt#)

See Dm-crypt with LUKS/Encrypting a non-root file system and Dm-crypt with LUKS/Encrypting an entire system.

Drive preparation

This step will deal with operations like securely erasing the drive and partitioning it. See Dm-crypt with LUKS/Drive Preparation.

Device encryption

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Add some introductory text with links to the most important subsections of Dm-crypt with LUKS/Device Encryption. (Discuss in Talk:Dm-crypt#)

See Dm-crypt with LUKS/Device Encryption.

System configuration

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Add some introductory text with links to the most important subsections of Dm-crypt with LUKS/System Configuration. (Discuss in Talk:Dm-crypt#)

See Dm-crypt with LUKS/System Configuration.

Examples

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: This section is an alternative to #Common scenarios, see Talk:Dm-crypt_with_LUKS/draft#New_idea. Add some introductory text with links to the most important subsections of Dm-crypt with LUKS/Examples. (Discuss in Talk:Dm-crypt#)

See Dm-crypt with LUKS/Examples.

Swap device encryption

A swap partition may be added to an encrypted system, if required. The swap partition must be encrypted as well to protect any data swapped out by the system. This part details methods without and with suspend-to-disk support.

See Dm-crypt with LUKS/Swap Encryption.

Specialties

This part deals with special operations like securing the unencrypted boot partition, using GPG or OpenSSL encrypted keyfiles, a method to boot and unlock via the network, or setting up discard/TRIM for a SSD.

See Dm-crypt with LUKS/Specialties.

Securing the unencrypted boot partition

Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks files under /boot for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR. The script cannot prevent certain type of attacks, but a lot are made harder. No configuration of the script itself is stored in unencrypted /boot. With a locked/powered-off crypted system this makes it infeasible for an attacker to recognize that an automatic checksum comparison of the partition is done upon boot.

The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2). There is also an AUR package: chkbootAUR and a slightly updated AUR package chkboot-gitAUR which includes systemd support.

After installation:

  • For classical sysvinit: add /usr/local/bin/chkboot.sh & to your /etc/rc.local
  • For systemd: add a service file and enable the service: systemd. The service file might look like:
[Unit]
Description=Check that boot is what we want
Requires=basic.target
After=basic.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/chkboot.sh

[Install]
WantedBy=multi-user.target

There is a small caveat for systemd: At the time of writing the original chkboot.sh script provided contains an empty space at the beginning of #!/bin/bash which has to be removed for the service to start successfully.

As /usr/local/bin/chkboot_user.sh need to be excuted after login, add it to the autostart (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart; Gnome3: gnome-session-properties).

With Arch Linux changes to /boot are pretty frequent, for example by new kernels rolling-in. Therefore it may be helpful to use the scripts with every full system update. One way to do so:

#!/bin/bash
#
# Note: Insert your <user>  and execute it with sudo for pacman & chkboot to work automagically
#
echo "Pacman update [1] Quickcheck before updating" & 
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user> 
/usr/local/bin/chkboot.sh
sync							# sync disks with any results 
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user> 
echo "Pacman update [2] Syncing repos for pacman" 
pacman -Syu
/usr/local/bin/chkboot.sh
sync	
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user>
echo "Pacman update [3] All done, let's roll on ..."

Alternatively to above scripts, a hash check can be set up with AIDE which can be customized via a very flexible configuration file.

While one of these methods should serve the purpose for most users, they do not address all security problems associated with the unencrypted /boot. One approach which endeavours to provide a fully authenticated boot chain was published with POTTS as an academic thesis to implement the STARK authentication framework.

The POTTS proof-of-concept uses Arch Linux as a base distribution and implements a system boot chain with

  • POTTS - a bootmenu for a one-time authentication message prompt
  • TrustedGrub - a grub-legacy implementation which authenticates the kernel and initramfs against TPM chip registers
  • TRESOR - a kernel patch which implements AES but keeps the master-key not in RAM but in CPU registers during runtime.

As part of the thesis installation instructions based on Arch Linux (iso 2013-01) have been published. If you want to try it, be aware these tools are not in standard repositories and the solution will be time consuming to maintain.

See also

  • cryptsetup FAQ - The main and foremost help resource, directly from the developers.
  • FreeOTFE - Supports unlocking LUKS encrypted volumes in Microsoft Windows.